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)
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.