Dependency Injection Inversion Rejection

Uncle Bob has done it again.  In his latest post, he actually advises people to go back to manual dependency injection instead of relying on a framework (our beloved IOC containers) to do it for us.  You really ought to check out the post and his examples in particular.  Done with that? Ok.

There are two major problems that i have with his post.  The first is this one:

I like this because now all the Guice is in one well understood place. I don’t have Guice all over my application. Rather, I’ve got factories that contain the Guice. Guicey factories that keep the Guice from being smeared all through my application.

What’s more, if I wanted to replace Guice with some other DI framework, I know exactly what classes would need to change, and how to change them. So I’ve kept Guice uncoupled from my application.

For those of you who don’t know, Guice is an IOC container from Google.  Uncle Bob doesn’t want references of an IOC container spread out throughout his application, but he doesn’t seem to mind coupling his factories with his IOC container for some reason.  He seems to think that he can actually switch to a different container more easily because of this, because he would only have to modify his factories.

Here’s the deal.  If you have more than a handful of references to your IOC container in your code (apart from the registration obviously), then you really don’t know what using an IOC container is all about.  Yes, i know Uncle Bob is supposed to be a legend.  Yes, i realize that i’m saying that a legend in the OO world doesn’t seem to grasp some of the most important concepts of using an IOC container.  Can you really disagree with that after reading his post?

His whole idea of making it easier to switch to another container with his approach is ludicrous.  He would have to modify every single factory that he uses, and in his trivial non-real world examples that wouldn’t be a lot to do but out here in the real world, we’d end up with a boatload of those factories and they would all have to be modified.  Conversely, if you’re using an IOC container in the way it is meant to be used, you’d only have to change your registration code and the one or two places where you resolve something manually through the container.  And that’s it.  Yes, you typically only need one or two places where you use the container directly.  Well, unless you’re Uncle Bob of course.

My other problem with his post is with the sample that he uses.  It really is a very simplistic example and the approach he outlines simply does not scale when you’re dealing with large, real-world codebases.  His approach might work for the size of the examples in his books, or for the code of Fitnesse, but if i were to apply his recommended approach for some of the systems that we’re working on, it would lead to a terrible mess very quickly.  Not exactly what i’d have in mind when thinking of Clean Code.

The one thing i do like about this post? Well, there are quite a few people who follow Uncle Bob blindly and can’t say a single bad thing about his thoughts/ideas/approaches.  I know quite a few of them make extensive use of IOC containers and some of them are even involved in the development of these containers.  Hopefully, Uncle Bob’s post will finally convince these people that blindly following anyone is simply never a good idea and that you have to keep a critical mindset for everything that you read, no matter who wrote it.