76

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?

Improve this question
16
  • 1
    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
    Commented Nov 15, 2010 at 23:32
  • 18
    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
    Commented Nov 16, 2010 at 1:06
  • 3
    @Steven, his boss might have asked him to do it.
    – user1249
    Commented Nov 16, 2010 at 5:17
  • 1
    @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
    Commented Nov 16, 2010 at 11:49
  • 3
    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
    Commented Dec 15, 2010 at 16:30

5 Answers 5

Reset to default
57

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.

Improve this answer
6
  • 3
    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
    Commented Jan 14, 2012 at 18:47
  • @ArneEvertsson Listen to Robert C. Martin talk about the Open-Closed Principle. You will be enlightened.
    – Alternatex
    Commented Apr 20, 2016 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
    Commented Jul 6, 2016 at 17:04
  • 2
    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
    Commented Jul 6, 2016 at 17:07
  • 3
    I downvoted this answer years ago; here are some remarks: 1) In practice, extensive use of DI tends to work against SRP, because programmers simply keep adding methods to their injected "controllers", "services", "DAOs", etc., instead of creating new classes for new functionality. It's what you normally see happening in Java and C#.NET projects which use some DI framework or container. 2) The open-closed principle was just Bertrand Meyer's delusion about the usefulness of class (implementation) inheritance; if you search it in his 1400+ page book you'll see what I mean - it's truly silly.
    – Rogério
    Commented Mar 6, 2018 at 15:21
9

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.

Improve this answer
4

Advantages of dependency injections are:

  1. Your code is clean and more readable.
  2. Codes 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.
Improve this answer
2

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.

Improve this answer
5
  • 2
    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
    Commented Dec 15, 2010 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
    Commented Dec 16, 2010 at 18:11
  • 1
    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
    Commented May 7, 2015 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
    Commented May 7, 2015 at 19:37
  • 1
    @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
    Commented May 7, 2015 at 19:39
-1

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

Improve this answer
2
  • 2
    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
    Commented May 7, 2015 at 19:10
  • I've forgotten.
    – thomas-peter
    Commented May 9, 2015 at 8:39

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