Does it make sense to assemble my project with dependency injection containers if I am the only one who will use the code of that project?

The question came up when I read this IOC Article http://martinfowler.com/articles/injection.html

The justification for using dependency injection in this article is that friends can reuse a class, and replace depending classes with their own classes because they get injected and not instantiated in the class.

I would only use it to inject objects where they are needed instead of passing them through layers to their target. (Which is not so bad I learned here: Is it bad practice to pass instances through several layers?)

(Maybe I will reuse parts of the project, who knows, but I don´t know if that is a good justification)

2 Answers 2


How the code is consumed and how many people are working on the project are orthogonal to the decision to use IoC containers or not.

They're a mechanism for providing unknown (and possibly changing post-deploy) implementations for a given interface, often via configuration. Do you need that mechanism? Then consider using them. If not, then don't.

Personally I find Spring-like containers to be oftentimes more trouble than the problem they're solving. Supplying dependencies via a constructor parameter or simple factory are often good enough. They tend to be easier to debug, and a lot less error-prone due to the lack of configuration.


To me DI is a good way to keep classes simple and with a single responsability. Also, when you (unit) test them you'll thank their dependencies (probably mocks) are easily injectable.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.