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

Answer 1

A couple of points:

• DI increases complexity, usually by increasing the number of classes since responsibilities are separated more, which is not always beneficial
• Your code will be (somewhat) coupled to the dependency injection framework you use (or more generally how you decide to implement the DI pattern)
• DI containers or approaches that perform type resolving generally incur a slight runtime penalty (very negligible, but it's there)

Generally, the benefit of decoupling makes each task simpler to read and understand, but increases the complexity of orchestrating the more complex tasks.

Answer 2

It can increase app startup time because IoC container should resolve dependencies in a proper way and it sometimes requires to make several iterations.

Answer 3

Two things:

• They require extra tool support to check that the configuration is valid.

For example, IntelliJ (commercial edition) has support for checking the validity of a Spring configuration, and will flag up errors such as type violations in the configuration. Without that kind of tool support, you can't check whether the configuration is valid before running tests.

This is one reason why the 'cake' pattern (as it's known to the Scala community) is a good idea: the wiring between components can be checked by the type checker. You don't have that benefit with annotations or XML.

• It makes global static analysis of programs very difficult.

Frameworks like Spring or Guice make it difficult to determine statically what the object graph created by the container will look like. Although they create an object graph when the container is started up, they don't provide useful APIs that describe the object graph that /would/ be created.

Answer 4

DI is a technique or a pattern and not related to any framework. You can wire up your dependencies manually. DI helps you with SR (Single responsibility) and SoC (separation of concerns). DI leads to a better design. From my point of view and experience there are no downsides. Like with any other pattern you can get it wrong or misuse it (but what is in the case of DI quite hard).

If you introduce DI as principle to a legacy application, using a framework - the single biggest mistake you can do is to misuse it as a Service-Locater. DI+Framework itself is great and just made things better everywhere I saw it! From organizational standpoint, there are the common problems with every new process, technique, pattern, ...:

• You have to train you team
• You have to change your application (which include risks)

In general you have to invest time and money, beside that, there a no downsides, really!

Answer 5

I have been using Guice (Java DI framework) extensively for the past 6 months. While overall I think it is great (especially from a testing perspective), there are certain downsides. Most notably:

• Code can become harder to understand. Dependency injection can be used in very... creative... ways. For example I just came across some code that used a custom annotation to inject a certain IOStreams (eg: @Server1Stream, @Server2Stream). While this does work, and I'll admit has a certain elegance, it makes understanding the Guice injections a prerequisite to understanding the code.
• Higher learning curve when learning project. This is related to point 1. In order to understand how a project that uses dependency injection works, you need to understand both the dependency injection pattern and the specific framework. When I started at my current job I spent quite a few confused hours groking what Guice was doing behind the scenes.
• Constructors become large. Although this can be largely resolved with a default constructor or a factory.
• Errors can be obfuscated. My most recent example of this was I had a collision on 2 flag names. Guice swallowed the error silently and one of my flags wasn't initialized.
• Errors are pushed to run-time. If you configure your Guice module incorrectly (circular reference, bad binding, ...) most of the errors are not uncovered during compile-time. Instead, the errors are exposed when the program is actually run.

Now that I've complained. Let me say that I will continue to (willingly) use Guice in my current project and most likely my next. Dependency injection is a great and incredibly powerful pattern. But it definitely can be confusing and you will almost certainly spend some time cursing at whatever dependency injection framework you choose.

Also, I agree with other posters that dependency injection can be overused.

Answer 6

It seems like the supposed benefits of a statically-typed language diminish significantly when you're constantly employing techniques to work around the static typing. One large Java shop I just interviewed at was mapping out their build dependencies with static code analysis...which had to parse all the Spring files in order to be effective.