4 ms·

If I read that correctly--and I most likely did not--it seems that he's making the argument that a misunderstanding of semantics and clear definitions lead to p

If I read that correctly--and I most likely did not--it seems that he's making the argument that a misunderstanding of semantics and clear definitions lead to poor implementation of DI, IoC, and DIP. The final case seems to mostly address Java's flagrant mis/overuse of interfaces. Like you, though, I struggle to find a clear message. Is this a complaint about things being done wrong? The solution presented around Dependency Inversion Principles was really tough to understand. It looks like he just made everything harder. It's been so long since I've done anything but front-end web work, though, that might just be me.

kasey_junk 12y ago
Thanks for the feedback. This was an article I wrote after having a few discussions with developers where people were confusing DI, IoC, and DIP (and IoC containers were thrown in as well). I posted it today as there were several other articles that were also mixing the topics up. My hope was to make the differences more clear. Not accomplishing that was the more probable outcome ;)
- mongol 12y ago
  Why should one not use setter methods?
  - chrisguitarguy 12y ago
    If your objects require dependencies to do their jobs, it should be impossible to create objects without those dependencies. The objects' constructors should require them. Having setters is, arguably, fine (but probably unnecessary) as long as invalid objects can't be created.
  - Roboprog 12y ago
    http://en.wikipedia.org/wiki/Class_invariant http://en.wikipedia.org/wiki/Class_invariant (above is a special case of below) http://en.wikipedia.org/wiki/Design_by_contract http://en.wikipedia.org/wiki/Design_by_contract Alas, Eiffel looked like Modula (Pascal), rather than like C/C++, so it never caught on. The important part, though, was the idea of class invariants + method pre-conditions + method post-conditions. Meyer's book, from years before Java and "Java beans" infected the group-think, talked about classes that explicitly were constructed in a valid state (which also meshes well with the practice of immutability), and methods with explicit conditions of their requirements and what they were guaranteeing they would accomplish. "Java beans" pretty much took these otherwise sound engineering principles and pissed all over them. Rather than having a constructor that builds an object that you can then start using, you have to guess (unless documentation is very good, which it won't be) which setters must be called before "bean" is non-crap. Yes, I'm bitter that such an obviously flawed practice became standard operating procedure, to the point that doing things right is viewed as suspect.
  - dack 12y ago
    Setters basically send a signal to the developer that the dependency is "optional", since someone can create the object and simply not call the setter. Most of the time, the dependencies are assumed to be set in, and will blow up at run-time when they are attempted to be accessed. By using constructor injection you prevent this from happening. Also, consider a case of refactoring. You have a class that is being created from a few places and add a new dependency via a setter to it. Compile your code, and it looks fine but actually isn't - you need to find all the places you create that object and provide the extra dependency. If you use constructor injection, you'd have a compile error (in a statically typed language) in all the places that need to be fixed.
  - kasey_junk 12y ago
    Using dependency injection adds complexity. You have to reason about how the injected functionality can change. If you use setter based injection (as opposed to constructor or parametric injection) then you also add the complexity of reasoning about when it can change.
- Roboprog 12y ago
  Thank you, loved it. I think the DIP part could use a little more explanation, but the DI/IoC parts very much hit home with me, underscoring some points I have also been trying to get across to people.

kasey_junk 12y ago

Thanks for the feedback. This was an article I wrote after having a few discussions with developers where people were confusing DI, IoC, and DIP (and IoC containers were thrown in as well). I posted it today as there were several other articles that were also mixing the topics up. My hope was to make the differences more clear. Not accomplishing that was the more probable outcome ;)

mongol 12y ago
Why should one not use setter methods?
- chrisguitarguy 12y ago
  If your objects require dependencies to do their jobs, it should be impossible to create objects without those dependencies. The objects' constructors should require them. Having setters is, arguably, fine (but probably unnecessary) as long as invalid objects can't be created.
- Roboprog 12y ago
  http://en.wikipedia.org/wiki/Class_invariant http://en.wikipedia.org/wiki/Class_invariant (above is a special case of below) http://en.wikipedia.org/wiki/Design_by_contract http://en.wikipedia.org/wiki/Design_by_contract Alas, Eiffel looked like Modula (Pascal), rather than like C/C++, so it never caught on. The important part, though, was the idea of class invariants + method pre-conditions + method post-conditions. Meyer's book, from years before Java and "Java beans" infected the group-think, talked about classes that explicitly were constructed in a valid state (which also meshes well with the practice of immutability), and methods with explicit conditions of their requirements and what they were guaranteeing they would accomplish. "Java beans" pretty much took these otherwise sound engineering principles and pissed all over them. Rather than having a constructor that builds an object that you can then start using, you have to guess (unless documentation is very good, which it won't be) which setters must be called before "bean" is non-crap. Yes, I'm bitter that such an obviously flawed practice became standard operating procedure, to the point that doing things right is viewed as suspect.
- dack 12y ago
  Setters basically send a signal to the developer that the dependency is "optional", since someone can create the object and simply not call the setter. Most of the time, the dependencies are assumed to be set in, and will blow up at run-time when they are attempted to be accessed. By using constructor injection you prevent this from happening. Also, consider a case of refactoring. You have a class that is being created from a few places and add a new dependency via a setter to it. Compile your code, and it looks fine but actually isn't - you need to find all the places you create that object and provide the extra dependency. If you use constructor injection, you'd have a compile error (in a statically typed language) in all the places that need to be fixed.
- kasey_junk 12y ago
  Using dependency injection adds complexity. You have to reason about how the injected functionality can change. If you use setter based injection (as opposed to constructor or parametric injection) then you also add the complexity of reasoning about when it can change.
Roboprog 12y ago
Thank you, loved it. I think the DIP part could use a little more explanation, but the DI/IoC parts very much hit home with me, underscoring some points I have also been trying to get across to people.