If all objects are untied

I have one question that I cannot answer anywhere. This applies to decoupling code from interfaces. The question is, should ALL objects inside other objects (created and used) be refactored into the interface in order to follow the principle of SOLID dependency inversion? What about new objects inside an even managed method ?, for example. a method called when I press a button. Should an object go through, say, a constructor? Of course, all this applies to my objects, and not to BCL?

+4
source share
1 answer

millimoose gave a great answer. This is especially good because it is the right answer for any programming problem :)

I just would like to tell a little. When using such scenarios, the following conditions are true:

  • The denouement is at its own expense.
  • No code would be perfect, since you probably won’t get it all the time when you want to work on it.
  • This is not the end of the world if your code is more connected than it can be.

Therefore, do not look at it in terms of the sentence "all or nothing" and instead look at it as an assessment. What connection are you willing to put up? How much are you willing to pay for the denouement? At some point, there is a balance between design time and perceived maintainability - given that you don't even know how your code will change.

Have you heard of the book Event-Based Programming: Taking Events to the Limit? All about communication: http://books.google.com/books?id=9CL446IzhuAC&pg=PR21&dq=taking+events+to+the+limit&hl=en&sa=X&ei=bcfLUMzRMcWLqgHi-oHoBw&ved=0CDUQ6wEwAA

The author claims that you cannot eliminate all the connections, but you can transform it, and the connection should be transferred to simpler classes. Perhaps you can use this as a guide for your efforts.

+5
source

All Articles