Possible Duplicate:
Difference between Dependency Injection (DI) & Inversion of Control (IOC)

I'm new to Inversion of Control, Dependency Injection and everything related to these stuff, so excuse me if I'm not specific in my question: Is there any magical piece of code, a good explanation or a link, so I can finally distinguish the concepts?

I really think that using Dependency Injection already means using Inversion of Control, but is there any way of using Inversion of Control without using Dependency Injection?

I've already read Martin Fowler's articles but I still find the concepts very confusing.

  • Well, what exactly confuses you? What do you think each of the concepts entails?
    – yannis
    Jan 23, 2012 at 2:19
  • I really think that using Dependency Injection already means using Inversion of Control,but my question is: Is there any way of using Inversion of Control without using Dependency Injection? Jan 23, 2012 at 2:24
  • 1
    When asked for clarifications, you should add them in the question, instead of responding in comments. Don't worry about it this time, I did it for you, but keep it in mind... Comments are ephemeral and most of us don't bother reading them at all.
    – yannis
    Jan 23, 2012 at 2:30

2 Answers 2


Dependency Injection is one way that Inversion of Control is often implemented, but there are others. From the Wikipedia Inversion of control article:

Implementation techniques are influenced by the computer language used.

In Java there are six basic techniques to implement Inversion of Control. These are:

  1. using a factory pattern
  2. using a service locator pattern
  3. using a constructor injection
  4. using a setter injection
  5. using an interface injection
  6. using a contextualized lookup

Constructor, setter, and interface injection are all aspects of Dependency injection.

  • I already know that,thanks..., but I would like to know: Is there any other way of implementing Inversion of Control without using Dependency Injection? Jan 23, 2012 at 2:32
  • 1
    @Daniel The article I linked to and quoted above lists three other ways. Jan 23, 2012 at 2:33
  • Bill, the wikipedia articles on DI and IoC are, unfortunately, full of errors; it would be best to not refer to them, until they get fixed. The articles from Martin Fowler on IoC and DI do a much better job of correctly describing the concepts. The confusion between IoC (a much older concept) and DI originated from its improper use by the creator of the Spring framework, which couldn't come up with a good name for the new concept and so decided to (hugely) stretch the definition of IoC.
    – Rogério
    Apr 10, 2015 at 17:10

Inversion of Control is a general concept where normal control flow is “inverted” in some way.

By “normal” flow, I mean a traditional batch application flow: the code runs from beginning to end, creating resources, requesting data and providing output. Control flow is dictated by the application itself, calling into libraries and system facilities as necessary. Any inversion of this — where libraries rather than the application (using these terms somewhat loosely) drive control flow — is in some sense inversion of control.

One of the most common examples of IoC is an event loop. In an event loop, the GUI toolkit (or the operating system) is in control, calling back into your application to handle events and process input. The normal flow — requesting input & processing it — is inverted so that the input processor drives the application, rather than the other way around.

Dependency injection is a specific use of Inversion of Control, where control inversion is applied to the selection and allocation of dependencies. Rather than having a component instantiate the subcomponents it requires, the creating code (either application code, manually, or the DI container) instantiates the required subcomponents and injects them into the component.

  • This is not what Inversion of control means to me. Example - a class depending on the implementation of another class (e.g. a Bike class uses a Wheel class) and so the higher level object depends on a lower level implementation. Instead, if we want IoC, we would make the Bike class reference the the IWheel interface, so it now depends on an abstraction. And the Wheel class would implement the IWheel interface. Apr 16, 2012 at 4:33
  • 1
    @dodgy_coder What you are describing is just basic abstraction - making the Bike class reference the IWheel interface is just abstracting Bike from the implementation. If Bike then requires the Wheel to be provided to it, rather than creating one itself, then Bike is using dependency injection, which is a specific application of Inversion of Control. The interface isn't what makes it DI/IoC; the fact that the bike receives the wheel rather than creating it itself is what makes it DI/IoC. Apr 16, 2012 at 19:45
  • Thanks for the clarification. I just realised what I was talking about is known as the Dependency Inversion Principle (DIP) which is related to DI and IoC. Apr 17, 2012 at 8:23
  • Good and correct answer, except for the last paragraph. DI isn't a form of use of IoC, simply because there is no inversion of the flow of execution; rather, DI could be said to be an inversion in the initialization of objects, but even that would be an stretch. The true reason IoC gets confused with DI is that the original author of the injection technique couldn't come up with a good name for the new concept, so he "reused" an existing name ("IoC"); it was only years later that a different author came up with a good name ("DI").
    – Rogério
    Jun 28, 2015 at 16:39

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