The words invert or control are not used at all to define Inversion of Control in the definitions that I've seen.



inversion of control (IoC) is a programming technique, expressed here in terms of object-oriented programming, in which object coupling is bound at run time by an assembler object and is typically not known at compile time using static analysis. ~http://en.wikipedia.org/wiki/Inversion_of_control

Martin Fowler

Inversion of Control is a common pattern in the Java community that helps wire lightweight containers or assemble components from different projects into a cohesive application. ~ based on http://www.martinfowler.com/articles/injection.html (reworded)

So why is Inversion of Control named Inversion of Control? What control is being inverted and by what? Is there a way to define Inversion of Control using the terminology: invert and control?

  • 23
    Props for the person who can explain this in plain English. – Robert Harvey Jul 22 '13 at 16:39
  • 2
    If a definition used the word it was defining, that would be a failure of a dictionary. Similar logic applies here. – Izkata Jul 22 '13 at 20:11
  • 2
    See also on StackOverflow: What is Inversion of Control? – Izkata Jul 22 '13 at 20:33
  • 3
    @Izkata, it is very common for dictionaries to define phrases in terms of the phrase's own terms or synonymous terms. ie: the force of nature definition uses the words force and nature in its definition or the terms of service definition uses the words rules and service where rules is synonymous with terms. – Korey Hinton Jul 22 '13 at 20:46
  • 3
    I prefer to use the term "automated dependency injection" or ADI instead of IoC, for this very reason; Fowler himself mentions that most current paradigms in programming have some sort of "inversion of control", where that term is defined generally as "the relenquishing of the determinations of the code to be executed and the time at which it should be executed to an external controlling system, when such determinations are traditionally made by the program itself". Everything from hardware interrupts to event-driven programming to virtual machines and multitasking happens with IoC. – KeithS Jul 23 '13 at 1:12

Let's say you have some sort of "repository" class, and that repository is responsible for handing data to you from a data source.

The repository could establish a connection to the data source by itself. But what if it allowed you to pass in a connection to the data source through the repository's constructor?

By allowing the caller to provide the connection, you have decoupled the data source connection dependency from the repository class, allowing any data source to work with the repository, not just the one that the repository specifies.

You have inverted control by handing the responsibility of creating the connection from the repository class to the caller.

Martin Fowler suggests using the term "Dependency Injection" to describe this type of Inversion of Control, since Inversion of Control as a concept can be applied more broadly than just injecting dependencies in a constructor method.

| improve this answer | |
  • 3
    This is an example of dependency injection, but dependency injection is only a subset of inversion of control. There are other things totally unrelated to dependency injection that practice inversion of control. – dsw88 Jul 22 '13 at 18:00
  • 1
    @mustang2009cobra: Thanks. An example is what I was after, not a comprehensive catalog of instances where it occurs, and the term "Inversion of Control" is most closely associated with DI, not message passing or other similar concepts. – Robert Harvey Jul 22 '13 at 18:03
  • True, dependency injection is the most prevalent example of IoC, so an example of DI makes the most sense. Perhaps a small change to your answer specifying that this is a DI example, which is the most prominent type of IoC? – dsw88 Jul 22 '13 at 18:11
  • 1
    This is exactly what I was looking for! A lot of examples and definitions of IoC don't plainly specify what control is being inverted. I realize that there can be more to IoC than just dependency injection, but now something finally clicked in my brain. Thanks! – Korey Hinton Jul 23 '13 at 16:28

I don't think anyone can explain it better than Martin Fowler does, further down the article you linked to.

For this new breed of containers the inversion is about how they lookup a plugin implementation. In my naive example the lister looked up the finder implementation by directly instantiating it. This stops the finder from being a plugin. The approach that these containers use is to ensure that any user of a plugin follows some convention that allows a separate assembler module to inject the implementation into the lister.

As he explains in the paragraphs above that, this is not quite the same as the reason the term "Inversion of Control" originated.

When these containers talk about how they are so useful because they implement "Inversion of Control" I end up very puzzled. Inversion of control is a common characteristic of frameworks, so saying that these lightweight containers are special because they use inversion of control is like saying my car is special because it has wheels.

The question, is what aspect of control are they inverting? When I first ran into inversion of control, it was in the main control of a user interface. Early user interfaces were controlled by the application program. You would have a sequence of commands like "Enter name", "enter address"; your program would drive the prompts and pick up a response to each one. With graphical (or even screen based) UIs the UI framework would contain this main loop and your program instead provided event handlers for the various fields on the screen. The main control of the program was inverted, moved away from you to the framework.

Which is why he goes on to coin the term "Dependency Injection" to cover this specific implementation of Inversion of Control.

As a result I think we need a more specific name for this pattern. Inversion of Control is too generic a term, and thus people find it confusing. As a result with a lot of discussion with various IoC advocates we settled on the name Dependency Injection.

To clarify a little: Inversion of Control means anything which inverts the control structure of a program from the classic procedural design.

In days of yore, a key example of this was letting a framework handle communication between a UI and your code, rather than leaving your code to generate the UI directly.

In more recent times (when such frameworks pretty much dominated, so the question was no longer relevant), an example was inverting control over the instantiation of objects.

Fowler, and others, decided that the term Inversion of Control covered too many techniques and we needed a new term for the specific example of instantiation of objects (Dependency Injection) but, by the time that agreement had been made, the phrase "IoC Container" had taken off.

This muddies the water a lot, because an IoC container is a specific kind of Dependency Injection, but Dependency Injection is a specific kind of Inversion of Control. This is why you're getting such confused answers, no matter where you look.

| improve this answer | |

Here's the "regular" control flow programs usually followed:

  • Run commands sequentially
  • You maintain control over the control flow of the program

Inversion of Control "inverts" that control flow, meaning it flips it on its head:

  • Your program doesn't control the flow anymore. Rather than calling commands as you see fit, you wait for someone else to call you.

That last line is the important one. Rather than calling someone else when you feel like it, someone else calls you when they feel like it.

A common example of this is web frameworks such as Rails. You define Controllers, but you don't actually decide when those get called. Rails calls them when it decides there's a need.

| improve this answer | |
  • 19
    [insert obligatory "in Soviet" joke here] – Robert Harvey Jul 22 '13 at 17:35
  • 2
    Kidding aside, what I think you're describing is more like message passing, which has been a staple of OO for decades. – Robert Harvey Jul 22 '13 at 17:36
  • 3
    @JimmyHoffa - This is not wrong at all - see here. Inversion of control is a more general concept than creating dependencies, and dependency injection is just one form of IoC. – Lee Jul 22 '13 at 17:38
  • 7
    @JimmyHoffa: I disagree. This is as much a correct definition of Inversion of Control as your answer or Robert's, which is exactly the confusion Fowler describes when coining the phrase Dependency Injection (which is what you are both calling IoC). – pdr Jul 22 '13 at 17:39
  • 5
    I agree with this statement by @pdr: "Inversion of Control means anything which inverts the control structure of a program from the classic procedural design." That's what I'm describing, and that's generic inversion of control. Dependency injection is a type of IoC, but it's not the only thing that practices IoC – dsw88 Jul 22 '13 at 18:04

This is about who controls instantiation of dependencies.

Traditionally, when a class/method needs to use another class (dependency), it is instantiated by the class/method directly. It controls its dependencies.

With Inversion of Control (IoC), the caller passed in the dependency, hence it (or a higher up caller) instantiates the dependency. The caller controls the dependencies.

The control of where a dependency is instantiated has been inverted - instead of being at the "bottom", where the code that needs it exists, it is instantiated at the "top", where the code that needs it is being called.

| improve this answer | |
  • 2
    @RobertHarvey - how plain is plain? – Oded Jul 22 '13 at 16:41
  • 4
    @RobertHarvey Huh? This seems fairly plain to me... What's not plain? The word "instantiation" or "dependencies" ? – Jimmy Hoffa Jul 22 '13 at 17:36
  • This and the post be @dsw88 above are quite plain to me. Look, if I never had heard of IoC, I would intuitively think "Oh, where who gets to control something flips from one side to the other". Good job on this! – Oliver Williams Jul 12 '17 at 5:45
  • I prefer this answer to yours, @RobertHarvey, take it as you will. – amn Jul 12 at 19:19

Typically higher level code calls (ie, controls) lower level code. Main() calls function(), function() calls libraryFunction().

That can be inverted, so the low level library function at the bottom calls higher level functions.

Why would you do that? Middleware. Sometimes you want to control the top level and the bottom level, but there's a lot of work in the middle you just don't want to do. Take the implementation of quicksort in the C stdlib. You call quicksort at the top level. You hand qsort() a function pointer to your own function that implements a comparator on whatever you feel like. When qsort() is called, it calls this comparator function. qsort() is controlling/calling/driving your high level function.

| improve this answer | |

Here's a simple overview:

  1. Control refers to what the program does next
  2. On the top level, there are typically two things that control the control: the application itself and the user

In the olden days, control was owned by the application first and the user second. If the application needed something from the user, it would stop and ask and then move on to its next task. The user's interaction provided mostly data rather than controlling what the application did next. This is a little foreign to us nowadays since we don't see this type of behavior very often.

If we switch that around and give the user primary control, then we have inverted the control. This means that instead of the user waiting around for the application to give it something to do, the application sits around waiting for user to give it something to do. GUI's are a great example of this and pretty much anything with an event loop has inverted control.

Note that my example is on the top level and that this concept of inversion of control can be abstracted to different layers of control within the application (i.e. dependency injection). This may be why it is so hard to get a straight answer.

| improve this answer | |

Let us try to understand it through the two examples.

Example 1

In earlier days, apps used to generate command prompts to accept user inputs one after other. Today, UI frameworks instantiates various UI elements, loop through various events of those UI elements (like mouse hover, click etc.) and user/main programs provides hooks (for example UI event listeners in Java) for listening to those events. So the main UI element flow "control" is moved from user program to UI framework. In earlier days, it was in user program.

Example 2

Consider class CustomerProcessor below:

class CustomerProcessor
    SqlCustRepo custRepo = new SqlCustRepo(); 
    private void processCustomers()
            Customers[] custs = custRepo.getAllCusts();

If I want processCustomer() to be independent of any implementation of getAllCusts(), not just the one provided by SqlCustRepo, I will need to get rid of line: SqlCustRepo custRepo = new SqlCustRepo() and replace it with something more generic, capable of accepting varied type of implementation, such that the processCustomers() will simply work for any provided implementation. Above code (instantiating required class SqlCustRepo by main program logic) is a traditional way and it does not achieves this goal of decoupling processCustomers() from implementation of getAllCusts(). In inversion of control, the container instantiates the required implementation class (as specified by, say xml configuration), injects it in the main program logic which gets bound as per hooks specified (say by @Autowired annotation or getBean() method in spring framework).

Lets see how this can be done. Consider below code.


<beans xmlns="http://www.springframework.org/schema/beans"
    <bean id="custRepo" class="JsonCustRepo" />


interface ICustRepo 
{ ... }


class JsonCustRepo implements CustRepo
{ ... }


class App
    public static void main(String[] args) 
        ApplicationContext context = new ClassPathXmlApplicationContext("Config.xml");
        ICustRepo custRepo = (JsonCustRepo) context.getBean("custRepo");

We can also have

class GraphCustRepo implements ICustRepo { ... }   


<bean id="custRepo" class="GraphCustRepo">

and we will not need to change App.java.

Above the container (which is the spring framework) has the responsibility to scan xml file, instantiate the bean of specific type and inject it into the user program. User program have no control on which class is instantiated.

PS: IoC is generic concept and is achieved in many ways. Above examples achieves it by dependency injection.

Reference: Martin Fowler's article.

| improve this answer | |

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