Take the 2-minute tour ×
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.

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

Definitions

Wikipedia

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?

share|improve this question
11  
Props for the person who can explain this in plain English. –  Robert Harvey Jul 22 '13 at 16:39
    
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
2  
@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
1  
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

5 Answers 5

up vote 26 down vote accepted

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.

share|improve this answer
    
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
    
@mustang2009cobra: Done. –  Robert Harvey Jul 22 '13 at 18:14
    
Thanks, I can get behind this answer now. +1 –  dsw88 Jul 22 '13 at 18:31

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.

share|improve this answer
    
I normally don't vote that much but this is a great answer. 1 vote won't be enough. :( –  RJD22 Aug 8 '13 at 7:25

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.

share|improve this answer
8  
[insert obligatory "in Soviet" joke here] –  Robert Harvey Jul 22 '13 at 17:35
1  
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
2  
@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
4  
@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
3  
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

It 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 instantiates the dependency. The caller controls the dependencies.

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

share|improve this answer
1  
Not plain English. Fail. –  Robert Harvey Jul 22 '13 at 16:40
1  
@RobertHarvey - how plain is plain? –  Oded Jul 22 '13 at 16:41
2  
@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
    
@JimmyHoffa: See my answer, which provides a specific example. IoC is one of those troublesome terms that everybody uses but nobody explains; people use IoC containers in programs that don't require them because they misunderstand. That said, I think this answer had a couple of ninja edits. :) –  Robert Harvey Jul 22 '13 at 17:41

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.

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.