> I don't think this can be called DI Sure it can: http://en.wikipedia.org/wiki/Dependency_injection#Manually_injected_dependency http://en.wikipedia.org/wiki/

> I don't think this can be called DI Sure it can: http://en.wikipedia.org/wiki/Dependency_injection#Manually_injected_dependency http://en.wikipedia.org/wiki/Dependency_injection#Manually_i... http://www.martinfowler.com/articles/injection.html#ConstructorInjectionWithPicocontainer http://www.martinfowler.com/articles/injection.html#Construc... > because you're not injecting them, you're passing them to the constructor Injection simply means that the dependency is sent from outside the class. That's exactly what's happening in the constructor example. > The problem with this model is that you're polluting your constructors with non-functional arguments I don't consider it "pollution." Who says that IDependency is non-functional? I don't think I've ever injected a non-functional dependency. > if you want to change one of these, you have to change all your constructor calls! This is a red herring. If you have to change all your calls, you failed to make your code DRY. That's the programmer's fault. Use a factory or default arguments. 95% of the time, the reason for injecting a dependency is that you want to use a fake implementation in your unit tests, but a particular concrete example in your production code. Have the default constructor setup the concrete dependency and use the extra constructor for your unit tests. This works most of the time for me. interface IDependency { void doSomething(); } class Foo { Foo(IDependency) { ... } // for unit tests Foo() { this(new ConcreteDependency()); } // for production } Doing DI manually requires a little bit of skill, but not much. I actually find that it teaches design principles more than it requires apriori knowledge of them. Having never used a configuration-based DI tool, it wouldn't be fair for me to conclude with any comparison between the approaches. However, given that this conversation started when you complained that DI tools subvert a static type system, I'm inclined to believe that the DI tools introduce accidental complexities that outweigh their benefits in the simplest use cases.