What are the downsides to using Dependency Injection? [closed]

Answer 1

The biggest "downside" to Inversion of Control (not quite DI, but close enough) is that it tends to remove having a single point to look at an overview of an algorithm. That's basically what happens when you have decoupled code, though - the ability to look in one place is an artifact of tight coupling.

Answer 2

Code without any DI runs the well-known risk of getting tangled up into Spaghetti code - some symptoms are that the classes and methods are too large, do too much and cannot be easy changed, broken down, refactored, or tested.

Code with DI used a lot can be Ravioli code where each small class is like an individual ravioli nugget - it does one small thing and the single responsibility principle is adhered to, which is good. But looking at classes on their own it's hard to see what the system as a whole does, since this depends on how all these many small parts fit together, which is hard to see. It just looks like a big pile of small things.

By avoiding the spaghetti complexity of big bits of coupled code within a large class, you run the risk of another kind of complexity, where there are lots of simple little classes and the interactions between them are complex.

I don't think that this is a fatal downside - DI is still very much worthwhile. Some degree of ravioli style with small classes that do just one thing is probably good. Even in excess, I don't think that it is bad as spaghetti code. But being aware that it can be taken too far is the first step to avoiding it. Follow the links for discussion of how to avoid it.

Answer 3

I find that constructor injection can lead to big ugly constructors, (and I use it throughout my codebase - perhaps my objects are too granular?). Also, sometimes with constructor injection I end up with horrible circular dependencies (although this is very rare), so you may find yourself having to have some kind of ready state lifecycle with several rounds of dependency injection in a more complex system.

However, I favour construtor injection over setter injection because once my object is constructed, then I know without a doubt what state it is in, whether it is in a unit test environment or loaded up in some IOC container. Which, in a roundabout sort of way, is saying what I feel is the main drawback with setter injection.

(as a sidenote, I do find the whole topic quite "religious", but your mileage will vary with the level of technical zealotry in your dev team!)

Answer 4

One thing that makes me squirm a little with DI is the assumption that all injected objects are cheap to instantiate and produce no side effects -OR- the dependency is used so frequently that it outweighs any associated instantiation cost.

Where this is can be significant is when a dependency is not frequently used within a consuming class; such as something like an IExceptionLogHandlerService. Obviously, a service like this is invoked (hopefully :)) rarely within the class - presumably only on exceptions needing to be logged; yet the canonical constructor-injection pattern...

Public Class MyClass
    Private ReadOnly mExLogHandlerService As IExceptionLogHandlerService

    Public Sub New(exLogHandlerService As IExceptionLogHandlerService)
        Me.mExLogHandlerService = exLogHandlerService
    End Sub

     ...
End Class

...requires that a "live" instance of this service be provided, damned the cost/side-effects required to get it there. Not that it likely would, but what if constructing this dependency instance involved a service/database hit, or config file look-ups, or locked a resource until disposed of? If this service was instead constructed as-needed, service-located, or factory-generated (all having problems their own), then you would be taking the construction cost only when necessary.

Now, it is a generally accepted software design principle that constructing an object is cheap and doesn't produce side-effects. And while that's a nice notion, it isn't always the case. Using typical constructor-injection however basically demands that this is the case. Meaning when you create an implementation of a dependency, you have to design it with DI in mind. Maybe you would have made object-construction more costly to obtain benefits elsewhere, but if this implementation is going to be injected, it will likely force you to reconsider that design.

By the way, certain techniques can mitigate this exact issue by allowing lazy-loading of injected dependencies, e.g. providing a class a Lazy<IService> instance as the dependency. This would change your dependent objects' constructors and make then even more cognizant of implementation details such as object construction expense, which is arguably not desirable either.

Answer 5

If you have a home-grown solution, the dependencies are right in your face in the constructor. Or maybe as method parameters which again is not too hard to spot. Though framework managed dependencies, if taken to the extremes, can begin to appear like magic.

However, having too many dependencies in too many classes is a clear sign that you're class structure is screwed up. So in a way dependency injection (home-grown or framework managed) can help bring glaring design issues out that might otherwise be hidden lurking in the dark.

---

To illustrate the second point better, here's an excerpt from this article (original source) which I whole heartedly believe is the fundamental problem in building any system, not just computer systems.

Suppose you want to design a college campus. You must delegate some of the design to the students and professors, otherwise the Physics building won't work well for the physics people. No architect knows enough about about what physics people need to do it all themselves. But you can't delegate the design of every room to its occupants, because then you'll get a giant pile of rubble.

How can you distribute responsibility for design through all levels of a large hierarchy, while still maintaining consistency and harmony of overall design? This is the architectural design problem Alexander is trying to solve, but it's also a fundamental problem of computer systems development.

Does DI solve this problem? No. But it does help you see clearly if you're trying to delegate the responsibility of designing every room to its occupants.

Answer 6

Here's my own initial reaction: Basically the same downsides of any pattern.

• it takes time to learn
• if misunderstood it can lead to more harm than good
• if taken to an extreme it can be more work than would justify the benefit