Inversion of control

In software engineering, Inversion of Control (IoC) is an abstract principle describing an aspect of some software architecture designs in which the flow of control of a system is inverted in comparison to procedural programming.

In traditional programming the flow of the business logic is controlled by a central piece of code, which calls reusable subroutines that perform specific functions. Using Inversion of Control this "central control" design principle is abandoned. The caller's code deals with the program's execution order, but the business knowledge is encapsulated by the called subroutines.

In practice, Inversion of Control is a style of software construction where reusable generic code controls the execution of problem-specific code. It carries the strong connotation that the reusable code and the problem-specific code are developed independently, which often results in a single integrated application. Inversion of Control as a design guideline serves the following purposes:

• There is a decoupling of the execution of a certain task from implementation.
• Every system can focus on what it is designed for.
• The systems make no assumptions about what other systems do or should do.
• Replacing systems will have no side effect on other systems.

Inversion of Control is sometimes facetiously referred to as the "Hollywood Principle: Don't call us, we'll call you", because implementations typically rely on callbacks.

Background

Inversion of Control is not a new term in computer science. According to Martin Fowler^[1] the etymology of the phrase dates back to 1988. In another article he also discusses the kind of pattern many advocates actually mean when talking about Inversion of Control and that Dependency Injection is a more specific term for it ^[2].

Nonetheless, there is differing opinion on whether Inversion of Control is a design pattern, an architectural principle, or both. In an article by Shivprasad Koirala^[3] Inversion of Control with Dependency Injection is presented as a design pattern. It is a practical example of the first five techniques mentioned (see below section). He also shows that Dependency Injection might be a design pattern, whereas Inversion of Control is implemented using Dependency Injection. In an article by Mani Malarvannan^[4] Inversion of Control is presented as a design pattern using contextualized lookup. The use of a service locator is considered using the same design pattern. In an article by Loek Bergman^[5] it is presented as an architectural principle. Dependency injection being the design pattern as its most natural implementation.

In an article by Robert C. Martin^[6] the dependency inversion principle and abstraction by layering come together. His reason to use the term "inversion" is in comparison with traditional software development methods. He describes the uncoupling of services by the abstraction of layers, when he is talking about dependency inversion. The principle is used to find out where system borders are in the design of the abstraction layers.

Inversion of Control is highly associated with dependency injection and the dependency inversion principle. Dependency injection is the main method to implement Inversion of Control.

Implementation techniques

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.

In an original article by Martin Fowler,^[7] the first five different techniques are discussed. In a description about Inversion of Control types,^[8] the last one is mentioned. Often the contextualized lookup will be accomplished using a service locator.

More important than the applied technique, however, is the optimization of the purposes.A

Examples

public class ServerFacade
{
        public <K, V> V respondToRequest(K request) {
 
                if (businessLayer.validateRequest(request)) {
                        DAO.getData(request);
                        return Aspect.convertData(request);
                }
 
                return null;
        }
}

This basic outline in Java gives an example of code following the IoC methodology. It is important, however, that in the ServerFacade a lot of assumptions are made about the data returned by the data access object (DAO).

Although all these assumptions might be valid at some time, they couple the implementation of the ServerFacade to the DAO implementation. Designing the application in the manner of Inversion of Control would hand over the control completely to the DAO object. The code would then become

public class ServerFacade
{
        public <K, V> V respondToRequest(K request, DAO dao) {
                return dao.getData(request);
        }
}

The example shows that the way the method respondToRequest is constructed determines, if IoC is used. It is the way that parameters are used that define IoC. This resembles the message-passing style that some object-oriented programming languages have been using.

APIs that use inversion of control

SAX is an example of an API that uses inversion of control throughout (after initialisation). SAX is generally more efficient than DOM, but DOM is often considered more convenient to program with, because it is not necessary to deal with inversion of control.^[9]

See also

• Abstraction layer
• Asynchronous I/O
• Callback (computer science)
• Closure (computer science)
• Continuation
• Delegate (.NET)
• Dependency inversion principle
• Flow-based programming
• Implicit invocation
• Interrupt handler
• Message Passing
• Monad (functional programming)
• Observer pattern
• Publish/subscribe
• Service locator pattern
• Signal (computing)
• Software framework
• Strategy pattern
• User exit
• Visitor pattern
• XSLT is a data-driven scripting language, meaning that the input data controls which templates (methods) are executed and in what order. Templates automatically return control to the input data upon completion or by using the <xsl:apply-templates /> command.

References

1. ^ Inversion of Control on Martin Fowler's Bliki
2. ^ Inversion of Control
3. ^ Design pattern – Inversion of Control and Dependency injection by Shivprasad Koirala
4. ^ Design Better Software with the Inversion of Control Pattern by Mani Malarvannan
5. ^ Inside Architecture: write once, run anywhere by Loek Bergman
6. ^ The Dependency Inversion principle by Robert C. Martin
7. ^ Inversion of Control Containers and the Dependency Injection Pattern by Martin Fowler
8. ^ IoC Types
9. ^ Lara D'Abreo. "StAX: DOM Ease with SAX Efficiency". http://www.devx.com/Java/Article/30298/1954. Retrieved 30 August 2011.