I'm trying to introduce DI as a pattern here at work and one of our lead developers would like to know: What - if any - are the downsides to using the Dependency Injection pattern?
Note I'm looking here for an - if possible - exhaustive list, not a subjective discussion on the topic.
Clarification: I'm talking about the Dependency Injection pattern (see this article by Martin Fowler), not a specific framework, whether XML-based (such as Spring) or code-based (such as Guice), or "self-rolled".
Here's my own initial reaction: Basically the same downsides of any pattern.
Code readability. You'll not be able to easily figure out the code flow since the dependencies are hidden in XML files.
A couple of points:
Generally, the benefit of decoupling makes each task simpler to read and understand, but increases the complexity of orchestrating the more complex tasks.
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.
It can be dangerous for your career because it may increase your overall knowledge of good API design. Once you learn how proper loosely coupled code can look like, it may turn out that you will have to decline lots of job offers because you would otherwise have to work with tightly coupled legacy apps. Happens to me a lot :)
I don't think such a list exists, however try to read those articles:
It can increase app startup time because IoC container should resolve dependencies in a proper way and it sometimes requires to make several iterations.
If you're using DI without an IOC container, the biggest downside is you quickly see how many dependencies your code actually has and how tightly coupled everything really is. ("But I thought it was a good design!") The natural progression is to move towards an IOC container which can take a little bit of time to learn and implement (not nearly as bad as the WPF learning curve, but it's not free either). The final downside is some developers will begin to write honest to goodness unit tests and it will take them time to figure it out. Devs who could previously crank something out in half a day will suddenly spend two days trying to figure out how to mock all of their dependencies.
Similar to Mark Seemann's answer, the bottom line is that you spend time becoming a better developer rather than hacking bits of code together and tossing it out the door/into production. Which would your business rather have? Only you can answer that.
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.
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!)
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, ...:
In general you have to invest time and money, beside that, there a no downsides, really!
The same basic problem you often get with object oriented programming, style rules and just about everything else. It's possible - very common, in fact - to do too much abstraction, and to add too much indirection, and to generally apply good techniques excessively and in the wrong places.
Every pattern or other construct you apply brings complexity. Abstraction and indirection scatter information around, sometimes moving irrelevant detail out of the way, but equally sometimes making it harder to understand exactly what's happening. Every rule you apply brings inflexibility, ruling out options that might just be the best approach.
The point is to write code that does the job and is robust, readable and maintainable. You are a software developer - not an ivory tower builder.
EDIT - A couple of relevant links...
http://thedailywtf.com/Articles/The_Inner-Platform_Effect.aspx
This is more of a nitpick. But one of the downsides of dependency injection is that it makes it a little harder for development tools to reason about and navigate code.
Specifically, if you Control-Click/Command-Click on a method invocation in code, it'll take you to the method declaration on an interface instead of the concrete implementation.
This is really more of a downside of loosely coupled code (code that's designed by interface), and applies even if you don't use dependency injection (i.e., even if you simply use factories). But the advent of dependency injection is what really encouraged loosely coupled code to the masses, so I thought I'd mention it.
Also, the benefits of loosely coupled code far outweigh this, thus I call it a nitpick. Though I've worked long enough to know that this is the sort of push-back you may get if you attempt to introduce dependency injection.
In fact, I'd venture to guess that for every "downside" you can find for dependency injection, you'll find many upsides that far outweigh it.