Is there any hard data on the value of Inversion of control or dependancy injection?

Question

I've read a lot about IoC and DI, but I'm not really convinced that you gain a lot by using them in most situations.

If you are writing code that needs plugable components, then yes, I see the value. But if you are not, then I question whether changing a dependancy to a class to a dependancy of an interface is really gaining you anything, other than more typing.

In some cases, I can see where IoC and DI help with mocking, but if you're not using Mocking, or TDD then what's the value? Is this a case of YAGNI?

Answer 1

The most significant gains from DI are not necessarily due to the use of interfaces. You do not actually need to use interfaces to have beneficial effects of dependency injection. If there's only one implementation you can probably inject that directly, and you can use a mix of classes and interfaces.

You're still getting loose coupling, and quite a few development environments you can introduce that interface with a few keypresses if needed.

Hard data on the value of loose coupling I cannot give, but it's been a vision in textbooks for as long as I can remember. Now it's real.

DI frameworks also give you some quite amazing features when it comes to hierarchical construction of large structures. Instead of looking for the leanest DI framework around, I'd recommend you look for a full-featured one. Less isn't always more, at least when it comes to learning about new ways of programming. Then you can go for less.

Answer 2

Apart from testing also the loose coupling is worth it.

I've worked on components for an embedded Java system, which had a fixed configuration of objects after startup (about 50 mostly different objects).

The first component was legacy code without dependency injection, and the subobjects where created all over the place. Now it happened several times that for some modification some code needed to talk to an object which was only available three constructors away. So what can you do but add another parameter to the constructor and pass it through, or even store it in a field to pass it on later. In the long run things became even more tangled than they already where.

The second component I developed from scratch, and used dependency injection (without knowing it at the time). That is, I had one factory which constructed all objects and injected then on a need to know basis. Adding another dependency was easy, just add it to the factory and the objects constructor (or add a setter to avoid loops). No unrelated code needed to be touched.

Answer 3

I doubt you will have any hard data on it, so I will add some thoughts on it.

First, you don't use DI (or other SOLID principles) because it helps you do TDD. Its the other way around, you do TDD because it helps you with the design - which usually means you get code that follow those principles.

Discussing why to use interfaces is a different matter, see: http://stackoverflow.com/questions/667139/what-is-the-purpose-of-interfaces.

I will assume you agree that having your classes do many different things results in messy code. Thus, I am assuming you are already going for SRP.

Because you have different classes that do specific things, you need a way to relate them. If you relate them inside the classes (i.e. the constructors), you get plenty of code that uses specific versions of the classes. This means that making changes to the system will be hard.

You are going to need to change the system, that's a fact of software development. You can call YAGNI about not adding specific extra features, but not on that you won't be needing to change the system. In my case that's something really important as I do weekly sprints.

I use a DI framework where configuration is done through code. With a really small code configuration, you hook up lots of different relations. So, when you take away the discussion on interface vs. concrete classes, you are actually saving typing not the other way around. Also for the cases a concrete class is on the constructor, it hooks it up automatically (I don't have to configure) building the rest of the relations. It also allows me to control some objects life time, in particular I can configure an object to be a Singleton and it hands a single instance all the time.

Also note that just using these practices isn't more overhead. Using them for the first times, is what causes the overhead (because of the learning process + in some cases mind set change).

Bottom line: you ain't gonna need to put all those constructor calls all over the place to go faster.