Inversion of Control
(also known as the Hollywood Principle - “Don’t call us, we’ll call you”)
Inversion of Control is a common phenomenon that you come across when extending frameworks. Indeed it’s often seen as a defining characteristic of a framework.
The phenomenon is Inversion of Control (also known as the Hollywood Principle - “Don’t call us, we’ll call you”).
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
There are various ways we can plug our code in to be called.
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 you develop a session bean, you can implement various methods that are called by the EJB container at various lifecyle points. For example the Session Bean interface defines ejbRemove, ejbPassivate (stored to secondary storage), and ejbActivate (restored from passive state). You 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 you run into this effect in much simpler situations.
- A Template method pattern 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 you to create and clean up your test fixture. It does the calling, your code reacts - so again control is inverted.
There is some confusion these days over the meaning of inversion of control due to the rise of IoC containers; some people confuse the general principle here with the specific styles of inversion of control (such as dependency injection) that these containers use. The name is somewhat confusing (and ironic) since IoC containers are generally regarded as a competitor to EJB, yet EJB uses inversion of control just as much (if not more).
What is Inversion of Control pattern?
This is about who controls instantiation of dependencies.
It is a principle in software engineering which transfers the control of objects or portions of a program to a container or framework. Most often, we use it in the context of object-oriented programming.
Traditionally, when a class/method needs to use another class (dependency), it is instantiated by the class/method directly - our custom code makes calls to a library. The class/method controls its dependencies. IOC enables a framework to take control of the flow of a program and make calls to our custom code. To enable this, frameworks use abstractions with additional behavior built in. If we want to add our own behavior, we need to extend the classes of the framework or plugin our own classes.
If you follow these simple two steps, you have done inversion of control:
- Separate what-to-do part from when-to-do part.
- Ensure that when part knows as little as possible about what part; and vice versa.
Inversion of Control means anything which inverts the control structure of a program from the classic procedural design.
IoC (Inversion of Control) :- It’s a generic term and implemented in several ways (events, delegates etc).
Advantages
- decoupling the execution of a task from its implementation
- making it easier to switch between different implementations
- greater modularity of a program
- greater ease in testing a program by isolating a component or mocking its dependencies, and allowing components to communicate through contracts