Dependency InjectionMore than a testing seam

time to read 3 min | 553 words

Jacob Proffitt has a post about Dependency Injection, which he doesn't seem to like very much.

The real reason that DI has become so popular lately, however, has nothing to do with orthogonality, encapsulation, or other "purely" architectural concerns. The real reason that so many developers are using DI is to facilitate Unit Testing using mock objects. Talk around it all you want to, but this is the factor that actually convinces bright developers to prefer DI over simpler implementations.

I do wish that people would admit that DI doesn’t have compelling applicability outside of Unit Testing, however. I’m reading articles and discussions lately that seem to take the superiority of DI for granted

While the ability to easily mock the code is a nice property, it is almost a side benefit to the main benefits, which is getting low coupling between our objects. I get to modify my data access code without having to touch the salary calculation engine, that is the major benefit I get.

I have had more than one occasion to experience the result of not doing so, and I have seen the benefits of breaking the application to highly independent components that collaborate together to create a working whole.

Take that and join it with a powerful container (such as Windsor), and suddenly you gain a whole new insight into the way you are constructing your application, because the moment you are tunneling a lot of the dependencies through a single source, you find that there are a lot of smart things that you can do. Decorators, interceptors and proxies come immediately to mind, but there are quite a few other options as well.

All of this becomes particularly exasperating in the dead silence regarding TypeMock.

Type Mock is a great library, and you can check this blog to see my discussion with Eli Lupian about it. The main weakness of Type Mock is its power, it allow me to take shortcuts that I don't want to take, I want to get a system with low coupling and high cohesion.

And from the comments to that post, again by Jacob:

How can you say that dependency injection (I'm not taking on the whole inversion of control pattern, but I might. Jury's still out on that one.) creates loosely coupled units that can be reused easily when the whole point of DI is to require the caller to provide the callee's needs?

Because there isn't a coupling from the unit to its dependencies, and there shouldn't be a coupling between the caller to the callee's dependencies. But even without the use of an IoC container, you can get a lot of benefit from DI, just the ability to pass a CachingDbConnection instead of an IDbConnection is very valuable, and not, this is not something that you can just put in some sort of a factory or provider, because you want that kind of decision to be made on case by case basis.

Ugh. I wish Ayende would admit that the only advantage to DI in his examples is to allow the mock objects to work, is all. There is no other compelling reason.

Sorry, but I don't think that this is the case at all. Dependency Injection isn't (just) for testing, it is to Enable Change.

More posts in "Dependency Injection" series:

  1. (23 Aug 2007) Separating the Container
  2. (21 Aug 2007) Applicability, Benefits and Mocking
  3. (18 Aug 2007) IAmDonQuixote ?
  4. (18 Aug 2007) More than a testing seam