inversion of control (IoC)
Inversion of Control (IoC) is a term used in the context of object-oriented programming to describe a paradigm in which a multiple-use module calls a specific module. Module refers to delimited and independent parts of a software - these can be objects or classes.
The reversal of the control flow is not to be confused with the principle of the reversal of the dependencies (Dependency Inversion Principle), which is equally well-known in object-oriented programming. Rather, inversion of control flow can be a consequence of inversion of dependencies. Inversion of Control is also represented in common parlance as the application of the Hollywood principle: "Don't call us, we'll call you". There are two ways to implement IoC - Dependency Lookup and Dependency Injection. IoC is one possible way to reduce coupling.
As soon as event handling is to be provided by a reusable module, IoC is used. So it is not the specific modules that call the reusable modules for specific events, but the other way around. The multiple-usable module can be implemented also as a complete framework, in whose framework then the classes for specific and concrete applications are summarized. In IoC then the Framework takes over the role of the main program and cares for the life cycle of objects. For this purpose, the framework specifies an interface that must first be implemented by the specific modules so that it can then be called by the framework - this is also referred to as a callback mechanism. There are two possible forms of implementing IoC:
- Dependency Lookup, thereby a container Callbacks on the components as well as a Lookup context makes available. This approach is used for example with Enterprise JavaBeans or Apache Avalon. It is task of the individual components to realize the Lookup on resources over appropriate APIs of the Container.
- Dependency Injection is a special characteristic of the IoC.
In the following it is explained, what IoC for the practical software development can mean.
In a classical approach, it is common to hard- code classes and their dependencies. Here with concrete classes one works, which receive then over constructors or Properties appropriate dependencies.
The illustration clarifies this procedure - thereby LogManager is directly dependent on the concrete implementation of LogWriter. Thus already with the compilation is determined, which interactions with other objects are executed. So changes at runtime are not possible at all. Changes of other kind can be introduced only after previous modification of the source code and again following compilation.
It is more advantageous if this procedure is reversed. In this case, a component - the container shown in the figure - creates the objects and decides dynamically at runtime how and in what form concrete implementations are to be used. Since thus the container takes over the control, one speaks also of inversion of control. The use of this principle requires abstractions such as interfaces and the use of abstract classes, in order to be able to realize the possibility of the dynamic influence.