Comments on: Not so poor man’s dependency injection

By: Carsten

Carsten — Sat, 27 Feb 2010 15:27:43 +0000

I like the Poor Man’s IoC and whenever I stumble upon legacy code that has a lot of dependencies I’m tempted to refactor it to use this way of IoC. It’s an easy way to have testable code, and you get to good results very often. Unfortunatly I’ve come upon many places where this isn’t used and where is no room for refactorings, so I have to live with the untestable code or twist myself in various ways to get to a meaningful test.

By: Daniel Fernandes

Daniel Fernandes — Tue, 19 Jan 2010 08:55:49 +0000

*I actually don’t have a huge amount of experience with IoC containers, but that’s because like Uncle Bob, I’ve always tried to avoid them until absolutely necessary, however I do have first hand reports (within orgs I’ve worked for) of where IoC abuse has caused very expensive problems.

That rings a bell and it’s painful to both my ears.

By: Daniel Fernandes

Daniel Fernandes — Mon, 18 Jan 2010 18:08:42 +0000

Dependency Inversion Principle, really, should be the important principle that we should care about.
Dependency Injection is merely a simple technique that is built around limitations of platforms based around statically typed languages.

Poor Man Dependency Injection like you’re doing is detrimental, I think, to understanding what a class really does. Ideally I (not considering inheritance) should only have to check its public members to gain such knowledge, here by having a public default ctor, anyone using this class will have too too check this default ctor and therefore its implementation details.

And as Tim mentioned, IoC can indeed hide a lot of complexity with large object graphs. And to that I’d say that if the business focused part (ie, not the technical parts) of your system is that complex then you need to split it and use for instance messaging to avoid the Big Ball Of Mud syndrome.

Daniel

By: rob

rob — Mon, 18 Jan 2010 16:22:17 +0000

Hi Tim!

Your example of a Repository pattern implimentation sounds like a situation which justifies use of an IoC (however if you’re having to pass around lots of dependencies between collaborators it can often point to a code smell).

My point is not that you shouldn’t use IoC containers, just that you should think very carefully before you do and not be afraid of using poor man’s DI when it’s the more appropriate solution.

By: Tim Ross

Tim Ross — Mon, 18 Jan 2010 14:55:03 +0000

Hi Rob, the problem with poor man’s dependency injection in my experience is it gets very messy when your dependencies have dependencies. For example, a controller that takes a repository that takes a session. The construction get’s pretty chaotic and you have no control over the scope of an instance of a dependency. Using an IoC container will supply dependencies to the entire object graph and allow you to control the life cycle of objects. I tend to inject objects that I consider to be external collaborators, such as services, repositories, etc. In saying that, I have seen IoC usage get out of control, mainly when the container is treated as a service locator. Using an IoC with DI forces you to consider which objects you collaborate with, rather than making direct calls to the container. By carefully naming the interfaces you inject, it is easy to identify the roles and responsibilities of your collaborators.