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

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)

up vote 6 down vote accepted

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 acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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