There's been another round of anti-Dependency Injection chatter in the blogsphere, so here we go again. Ayende's done a pretty good job of defending his response to the original posting. The arguments are the same as usual: we don't see why we should change our design just to make it testable. I would like to add a few comments to this round.
- Static factories and the like are still dependencies, just implicit. Instead of making the dependencies clear in the code, so you can set up an object once and then just use it, statics force you to package up a load of hidden references with your class that aren't relevant after instantiation
- I don't go around exposing private features all over the place. I expose the parts that need exposing because they express a relationship with a collaborator
- As an author on the original papers, I resent quotes like
I wonder if this is a defensive reaction because the authors of the examples don’t want to have to justify making you fundamentally alter your coding habits and re-write all of your existing code just so that you can use their pet objects.I'm used to being disagreed with over this technique, but this is a new one on me. Our approach to design has a long and very respectable history. If you're not aware of its roots, then maybe you should alter your coding habits.
- I could do without some of the language, such as
"The emperor is naked" and you see it.and
Take a look at what people are asking for on the xxMocks forums and the yahoo test-driven group and you will see how every problem that the tool can't solve is actually a design smell. Pragmatic development teams don't believe this anymore.like we don't care about shipping reliable and effective systems.
One good thing this episode shows is that there are plenty of people who understand the issues and are prepared to engage.