119

I've been seeing a lot of references of Dependency Injection (DI) & Inversion Of Control (IOC), but I don't really know if there is a difference between them or not.

I would like to start using one or both of them, but I'm a little confused as to how they are different.

gnat
  • 21,442
  • 29
  • 112
  • 288
  • 2
    DI is a form of IoC, I gave a pretty detailed explanation of DI and IoC in [this answer](http://stackoverflow.com/questions/45191/ioc-explain-and-more-important-when-to-use-it#45197) –  Sep 26 '08 at 13:01
  • Inversion of Control usually refers to the "containers" while Dependency Injection refers to the actual pattern. But they go hand in hand. I would recommend reading [Martin Fowler's article](http://martinfowler.com/articles/injection.html) to get a handle on the topic. – Ben Hoffstein Sep 26 '08 at 12:56
  • So in other words, basically IoC is an implementation of using DI. Am I getting that correctly? – dance2die Mar 06 '09 at 14:59
  • Yes IOC frameworks tend to exploit DI techniques. – djna Dec 01 '09 at 10:21
  • Dependency Injection is a thing that you do, which leads to a command structure called Inversion of Control. They are inherently linked. –  Sep 26 '08 at 12:56
  • 2
    I'd say that DI is a special case of IOC. Traditional control goes module->request module from module manager, in DI it is inverted to module manager->get requested dependencies from module. – Rafał Dowgird Sep 26 '08 at 13:02
  • related: http://programmers.stackexchange.com/questions/131446/what-is-inversion-of-control-and-when-should-i-use-it – gnat Feb 10 '12 at 11:51
  • read this: http://programmers.stackexchange.com/questions/135914/why-was-dependency-injection-pattern-not-included-in-the-gang-of-four/135942#135942 – Dipan Mehta Mar 03 '12 at 14:32

4 Answers4

53

Definitions

Inversion of control is a design paradigm with the goal of reducing awareness of concrete implementations from application framework code and giving more control to the domain specific components of your application. In a traditional top down designed system, the logical flow of the application and dependency awareness flows from the top components, the ones designed first, to the ones designed last. As such, inversion of control is an almost literal reversal of the control and dependency awareness in an application.

Dependency injection is a pattern used to create instances of classes that other classes rely on without knowing at compile time which implementation will be used to provide that functionality.

Working Together

Inversion of control can utilize dependency injection because a mechanism is needed in order to create the components providing the specific functionality. Other options exist and are used, e.g. activators, factory methods, etc., but frameworks don't need to reference those utility classes when framework classes can accept the dependency(ies) they need instead.

Examples

One example of these concepts at work is the plug-in framework in Reflector. The plug-ins have a great deal of control of the system even though the application didn't know anything about the plug-ins at compile time. A single method is called on each of those plug-ins, Initialize if memory serves, which passes control over to the plug-in. The framework doesn't know what they will do, it just lets them do it. Control has been taken from the main application and given to the component doing the specific work; inversion of control.

The application framework allows access to its functionality through a variety of service providers. A plug-in is given references to the service providers when it is created. These dependencies allow the plug-in to add its own menu items, change how files are displayed, display its own information in the appropriate panels, etc. Since the dependencies are passed by interface, the implementations can change and the changes will not break the code as long as the contract remains intact.

At the time, a factory method was used to create the plug-ins using configuration information, reflection and the Activator object (in .NET at least). Today, there are tools, MEF for one, that allow for a wider range of options when injecting dependencies including the ability for an application framework to accept a list of plugins as a dependency.

Summary

While these concepts can be used and provide benefits independently, together they allow for much more flexible, reusable, and testable code to be written. As such, they are important concepts in designing object oriented solutions.

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
Chuck
  • 631
  • 4
  • 5
  • 3
    No, IoC is an older concept and it's independent of DI (which does not depend on IoC). For example, take the Struts framework (Java): it heavily relies on IoC, but makes no use of DI. – Rogério Jun 28 '15 at 16:24
  • 1
    @Rogério - You make a good point that the two concepts do not require each other. I updated my answer to clarify that and then quickly describe how some frameworks use them together to allow for code that is more loosely coupled. – Chuck Jun 28 '15 at 18:26
  • The simplest application of IoC, would probably be ActionListener. Instead of procedurally handling the code, the event handling code is delegated to custom code. Hereby inverting the control. – mike May 17 '17 at 10:10
0

Good article to understand IOC and DI http://martinfowler.com/articles/injection.html

IOC (Inversion of Control)

IOC means

  1. coding to interface (one component should dependent on other component’s interface and not on impl), and e.g 

    interface iComp_2 {...}

class Comp_1 {
    iComp_2 c2 = ….;
}

  2. removing the component implementation specific code e.g 

    Comp_1 {
    iComp_2 c2 = getComp_2_Impl(); // not new Comp_2_Impl();
}

IOC can be achieved by either of the following:

1. DI (Dependency Injection)

3 types of DI

1.1 Constructor Injection

1.2 Setter Injection

1.3 Interface Injection

2. Service Locator

DI (Dependency Injection) container

Runtime impl determination and not compile time: determines at runtime which concrete implementation of an interface to be used based on some config file (so at compile time we don’t know which impl is going to be used and thus increases configurability of the application). It is an implementation where the concrete relation between different modules is decided at "run time".

Instantiation of impl after dependency injection: after determining the impl, it instantiates that impl by first creating all of its dependencies (specified in config file) and then injecting those dependencies into that impl

Instance Life-cycle management: DI containers usually only keep a reference to objects it needs to manage life cycles for, or that are reused for future injections, like singletons or flyweights. When configured to create new instances of some components for each call to the container, the container usually just forgets about the created object. Otherwise the garbage collector would have a hard time collecting all these objects when no longer used.

  • 6
    Did you really read the "injection" article? IOC does *not* mean what this answer says, not at all. – Rogério Jun 28 '15 at 16:26
-3

I would say "Inversion of Control" is a way to design a system where all the modules are thought of abstract entities.

And, "Dependency Injection" is an implementation where the concrete relation between different modules is decided at "run time".

mB.
  • 111
  • 3
-4

Inversion of control is a general concept, in functional languages is usually done using continuations. This let's you write an API where both sides are 'caller', and none the 'callee'. In other, more static environments you don't have this facillity, so you need this hack to insert hints into the control flow.

Javier
  • 9,888
  • 1
  • 26
  • 35