Inversion of Control is a common phenomenon that we come across when extending frameworks. Indeed it’s often seen as a defining characteristic of a framework.

Let’s consider a simple example. Imagine I’m writing a program to get some information from a user and I’m using a command line enquiry. I might do it something like this

1
#ruby
2
puts 'What is your name?'
3
name = gets
4
process_name(name)
5
puts 'What is your quest?'
6
quest = gets
7
process_quest(quest)

In this interaction, my code is in control: it decides when to ask questions, when to read responses, and when to process those results.

However if I were to use a windowing system to do something like this, I would do it by configuring a window:

1
require 'tk'
2
root = TkRoot.new()
3
name_label = TkLabel.new() {text “What is Your Name?”}
4
name_label.pack
5
name = TkEntry.new(root).pack
6
name.bind(“FocusOut”) {process_name(name)}
7
quest_label = TkLabel.new() {text “What is Your Quest?”}
8
quest_label.pack
9
quest = TkEntry.new(root).pack
10
quest.bind(“FocusOut”) {process_quest(quest)}
11
Tk.mainloop()

There’s a big difference now in the flow of control between these programs - in particular the control of when the process_name and process_quest methods are called. In the command line form I control when these methods are called, but in the window example I don’t. Instead I hand control over to the windowing system (with the Tk.mainloop command). It then decides when to call my methods, based on the bindings I made when creating the form. The control is inverted - it calls me instead of me calling the framework. This phenomenon is Inversion of Control.

One important characteristic of a framework is that the methods defined by the user to tailor the framework will often be called from within the framework itself, rather than from the user’s application code. The framework often plays the role of the main program in coordinating and sequencing application activity. This inversion of control gives frameworks the power to serve as extensible skeletons. The methods supplied by the user tailor the generic algorithms defined in the framework for a particular application.

- Ralph Johnson and Brian Foote

TIP

Inversion of Control (IoC) was first introduced in software engineering literature by Ralph E. Johnson and Brian Foote in their 1988 paper, Designing Reusable Classes (published in the Journal of Object-Oriented Programming)

Inversion of Control is a key part of what makes a framework different to a library. A library is essentially a set of functions that you can call, these days usually organized into classes. Each call does some work and returns control to the client.

A framework embodies some abstract design, with more behavior built in. In order to use it we need to insert our behavior into various places in the framework either by subclassing or by plugging in our own classes. The framework’s code then calls our code at these points.

There are various ways we can plug our code in to be called. In the ruby example above, we invoke a bind method on the text entry field that passes an event name and a Lambda as an argument. Whenever the text entry box detects the event, it calls the code in the closure. Using closures like this is very convenient, but many languages don’t support them.

Sometimes we want to combine several required method calls in a single unit of extension. In this case the framework can define an interface that a client code must implement for the relevant calls.

EJBs are a good example of this style of inversion of control. When we develop a session bean, we can implement various methods that are called by the EJB container at various lifecycle points. For example the Session Bean interface defines ejbRemove, ejbPassivate (stored to secondary storage), and ejbActivate (restored from passive state). We don’t get to control when these methods are called, just what they do. The container calls us, we don’t call it.

These are complicated cases of inversion of control, but we run into this effect in much simpler situations. A template method is a good example: the super-class defines the flow of control, subclasses extend this overriding methods or implementing abstract methods to do the extension. So in JUnit, the framework code calls setUp and tearDown methods for us to create and clean up our test fixture. It does the calling, our code reacts - so again control is inverted. This is also called Hollywood Principle as in GoF’s Template Method - “Don’t call us, we’ll call you”