Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 14 down vote favorite
8

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
9  
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
1  
@Steven, his boss might have asked him to do it. – user1249 Nov 16 '10 at 5:17
I think this has been answered to death on SO – Ken Liu Nov 16 '10 at 6:05
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 Nov 16 '10 at 11:49
1  
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
show 2 more comments

7 Answers

up vote 13 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
1  
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
up vote 7 down vote

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.

share|improve this answer
up vote 2 down vote

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
up vote 1 down vote

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
up vote 0 down vote

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
up vote 0 down vote

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). – Rogerio Dec 16 '10 at 18:11
up vote 0 down vote

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

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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