Benefits of implementation driven & dependency injection vs cost of maintaining implementations - spring

Question

I am starting an application that I would like to build quickly and will be later developed by 20+ developers.
Knowing what you know about DI in an environment with multiple developers, would you go with DI for a new application you'd like to build relatively fast?
The costs of using DI to me right now, would be lines of code written and generated vs not using an interface for every object. And down the line I am hoping DI doesn't become a performance problem because of reflection.

Answer 1

DI is basically not about frameworks. If you just add your dependencies, for example, as parameters to the constrictor, then you're doing DI. Actually you don't even need to create interfaces (though that would help testing. Introduce interface later is a simple refactoring in languages like Java). DI just removes the responsibility of creation from the user of the class.
The single greatest cost in my head would be change of mind. To learn to think DI.
benefits include easier testing. Separation of concern and more.

Answer 2

Simply said, doing Object-oriented development without dependency injection is bad. Very bad. Dependency injection is in my opinion the root of well-understood OO development: separation of concerns, loose coupling between independent components, coding in layers, all of that is done using DI. And also, it makes testing incredibly easier, and allows techniques like TDD, mocking (BDD), etc.
As Shakyamuni said in his answer, DI is not about the framework you use. Spring did not invent DI, it just proposes a solution to achieve it. So if your original question is "should we use Spring", then I'd say it's a question of personal taste. You can achieve exactly the same result if you do it yourself. I've worked in project with or without containers (Spring, pico, etc.) and they all have their benefits and drawbacks. My personal preference, though, is not to use any of it and manage your DI yourself.
This is DI:
// constructor
public MyClass(MyDependencyInterface injected) {
this.dependency = injected;
}
or that:
// setter injection
public void setDependency(MyDependencyInterface injected) {
this.dependency = injected;
}
And down the line I am hoping DI doesn't become a performance problem because of reflection.
No idea what you mean by that. DI does not require reflection.

Answer 3

I would definitely advocate DI, particularly when there are a lot of developers.
This allows each developer to write and test their own code without relying on injected components being developed outside of their control.
It can also facilitate interface definitions so everyone knows what functionality is available from which components.

Answer 4

The basic problem in Java is that when you in class A do a new B() this mean that class A is very tightly bound to class B at the byte code level.
This is typically a good thing as it means that the resulting application becomes very sturdy as all the "bricks" are very well "glued together".
You frequently, however, need to postpone some design issues to deploy time (and occasionally even runtime) and the way to handle this in Java has traditionally been to delegate to a Factory which perhaps even in turn delegates to another factory etc, until you reach the place where you make the decision. This is typically done with a property file containing either flags corresponding to if-statements in the code (which requires the programmer to foresee all situations when writing the code), or class names to resolve with Class.forName() (which is brittle as the compiler cannot help).
The advantage of Dependency Injection is that you sidestep the hard binding of the newoperator by delegating the responsibility to create an appropriate object outside of your own code (to a container but could as well be a deity). You create some very clear cut-lines where you can put things together and for those DI-frameworks providing code configuration (like Guice) the result can be as sturdy as well as modular.
Note that coding to interfaces makes it easier to identify the right places to make incisions for the cut-lines, because interface usages usually corresponds to injection points.