Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm planning to do a talk on Dependency Injection and IoC Containers, and I'm looking for some good arguments for using it.

What are the most important benefits of using this technique, and these tools?

share|improve this question
See here and here for StackOverflow answers and here for a good full article on IoC. And if you want arguments against it for comparison, head here on SO. – Jesse C. Slicer Nov 15 '10 at 23:32
not to be a butt...but if you don't know why DI/IOC should be used, why are you talking about it? lose a bet? ;-) – Steven A. Lowe Nov 16 '10 at 1:06
@Steven, his boss might have asked him to do it. – user1249 Nov 16 '10 at 5:17
@Steven, I already use DI all the time (some would say too often :-D), I'm just looking for some good arguments to get other people to use it. – Andy Lowry Nov 16 '10 at 11:49
People rarely talk about the overuse of DI. If you delay every single decision, you'll create the OO equivalent of spaghetti code. Having a coherent design requires that, at some point, a real decision is made. – Macneil Dec 15 '10 at 16:30
up vote 23 down vote accepted

Most important, for me, is making it easy to follow the Single Responsibility Principle.

DI/IoC makes it simple for me to manage dependencies between objects. In turn, that makes it easier for me to break coherent functionality off into it's own contract (interface). As a result, my code has been far more modularized since I learned of DI/IoC.

Another result of this is that I can much more easily see my way through to a design that supports the Open-Closed Principle. This is one of the most confidence inspiring techniques (second only to automated testing). I doubt I could espouse the virtues of Open-Closed Principle enough.

DI/IoC is one of the few things in my programming career that has been a "game changer." There is a huge gap in quality between code I wrote before & after learning DI/IoC. Let me emphasize that some more. HUGE improvement in code quality.

share|improve this answer
Why is the Open-Closed Principle such a big deal? If you feel you need to change an API/interface why shouldn't you? – Arne Evertsson Jan 14 '12 at 18:47
@ArneEvertsson Listen to Robert C. Martin talk about the Open-Closed Principle. You will be enlightened. – Alternatex Apr 20 at 11:31
@AmeEvertsson Open-Closed is very important when your code is supplied (e.g. as a commercial product) as a module for others to use, as it makes your code more adaptable in use without them reverting to you to change it – James Ellis-Jones Jul 6 at 17:04
DI doesn't make it simple to manage dependencies as its considerably more complex than simply creating a dependency to a concrete class. It does however provide flexibility but unless you are doing 'proper' unit testing, that flexibility will often not be needed. Both the key advantages described also apply to Service Locator, which is simpler. – James Ellis-Jones Jul 6 at 17:07

The examples that really opened my eyes were seeing how it made it possible to easily unit test the objects created in such a fashion. Prior to that, I had trouble attempting to isolate objects for a unit test. I would often write tests to interacted with a much larger system. This was really hard because the system as a whole was much less predictable and much more prone to change then the individual components.

share|improve this answer

Are you talking about Dependency Injection or Dependency Injection Frameworks? The two are very different: the first one is a good idea and you should use it, the second one is a crutch needed to use that good idea in badly designed programming languages, and you shouldn't use it, you should use a better language instead.

share|improve this answer
Bang. I'm learning Zend Framework 2. You just hit the nail on the head. – tomwrong Aug 2 '12 at 9:21
@jörg-w-mittag could you name an example of a good programming language that allows you to use dependency injection (with the kind of things you can do with Spring for instance) without any DI framework? – Clint Eastwood May 7 '15 at 18:59
@Jonathan: Newspeak is a good example. After all, it was designed by Gilad Bracha, who literally wrote the book (well, PhD thesis) on modularity. Scala is heavily inspired by Newspeak in this regard, so it's also a good example, look up the Cake Pattern and the Layer Cake Pattern. – Jörg W Mittag May 7 '15 at 19:04
very good finding, didn't know anything about it. I will take a look at that. Cheers! – Clint Eastwood May 7 '15 at 19:13

I think the actual benefits are more political than technical. DI is simply an alternative to the Service Locator pattern, nothing more. By itself, it does not make it easier to follow principles like SRP or OCP, or to decouple layers. Other respondents here are confusing different concepts and techniques, IMO.

You can achieve the same goals with respect to high cohesion and low coupling by using Service Locators, or by simply instantiating dependencies directly whenever applicable (which is most of the time).

Now, I know many will disagree with this opinion. I will be glad to discuss concrete examples.

share|improve this answer
But directly invoking a service locator or instantiating a concrete dependency usually hard-wires your dependencies, or at least where your dependencies come from. That seems to defeat the purpose of DI. You still have to inject the service locator, too. – Matt H Dec 15 '10 at 16:51
Using a Service Locator does not hard-wire anything except the use of the Service Locator class itself, which normally is not "injected". Instantiating a concrete implementation class is perfectly fine in cases where you don't need external configuration (for example, programmers usually instantiate directly the ArrayList class instead of using DI - which would be overkill). – Rogério Dec 16 '10 at 18:11
You mention "low coupling" and later on you say that a service locator has no impact on the level of coupling of an application. The same for instantiating collaborators directly on the code, I can't think of a more perfect way to couple an object with its dependencies. How do you unit test both scenarios? I, respectfully, completely disagree with everything you said. – Clint Eastwood May 7 '15 at 19:03
@Jonathan You should read the article that introduced DI then; the author concludes by saying DI and ServiceLocator are "roughly equivalent", with an "slight edge" for the latter. The coupling that matters is between a component and other components which may have multiple implementations; a ServiceLocator is an infrastructure service with only one implementation, so it's ok. Note I wrote "instantiating dependencies whenever applicable"; of course, if you need to separate configuration from use, you wouldn't do it. – Rogério May 7 '15 at 19:37
@Jonathan Regarding unit testing, it's a myth that instantiating collaborators prevents the creation of such tests; there are well-known mocking tools that do the job of isolating a class from dependency implementations, whether they are injected or not. – Rogério May 7 '15 at 19:39

The first and foremost thing is that it allows the decoupling of view and the logic of your application. Your view needn't know how the business logic, data etc are handled. This allows you to do quick UI changes, according to user experience feedback. Also if something on the back-end is changed the UI doesn't even have to modified a little.
MVC architecture uses this design pattern to separate the parts. It also allows for multiple persons to work together effectively in case of big enterprise applications.

share|improve this answer
Everyone loves the word decoupling. Decoupling is a great way of making certain components reusable. The problem is that some people have taken this and think that decoupling everything is good. It is simply not the case. Coupling is good, it allows for encapsulation and is one of the driving principle in OOP. When is decoupling good? When is follows DRY principles. ( It is also NOT for when you wish to make your testing easier). – tomwrong Aug 2 '12 at 9:40

When DI is used to expose inner objects for the purpose of testing, the pattern has been abused.

share|improve this answer
what do you mean by "inner objects"?. in real OOP (note that probably only 1% of the programmers know what that really means), there are objects communicating with each other by means of sending messages (i.e. method invocations). In that sense, each object must have a single responsibility, there aren't "more important" objects than others...every single one has a single duty and they cooperate to achieve the functionality provided by the whole system. It's important to test every object in an isolated manner so we know we didn't miss any case, that's what DI is really good at. – Clint Eastwood May 7 '15 at 19:10
I've forgotten. – tomwrong May 9 '15 at 8:39

Advantages of dependency injections are, 1.your code is clean and more readable. are loosely coupled. 3.more reusable as the implementations are configured in the XML file,it can be used in a different context. 4.code can be easily testable with different mock implementation.

share|improve this answer

protected by gnat Apr 20 at 6:27

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.