Inversion of control

Inversion of control it is a phenomenon that we come across when extending frameworks it can often be seen as defining characteristic of a framework.

Inversion of Control is a key part that makes a framework different to a library.

A library is essentially a set of functions that could be called, these days usually they are 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 needs to be inserted into various places in the framework either by subclassing or by plugging in the classes. The framework's code then calls code at these points.

It has followed the concept as the "Hollywood Principle" i.e."don't call us, we will call you". Is used as one approach where an individual can use to achieve loose coupling between several interacting components in an application.

INVERSION OF CONTROL

Assume two classes as Class A and Class B. Class A has a relationship with Class B: it wants to use the services of Class B. The usual way to establish this relationship is to instantiate Class B inside Class A. Though this approach works, it creates tight coupling between the classes. You can't easily change Class B without modifying Class A. To eliminate the coupling, you can have a Configurator inject the instance of Class B (Object "b") to the instance of Class A (Object "a"). If you want to change the implementation of Class B later on, you simply change the Configurator object. So, the control of how Object "a" gets the reference of Object "b" is inverted. Object "a" is not responsible for getting the reference to Object "b". Instead, the Configurator is responsible for it. This is the basis for the IoC design pattern.

SERVICE LOCATOR

Another way to decouple the objects: dependency lookup. This is implemented as a Service Locator pattern. In dependency lookup, the dependent object explicitly performs a look-up for the required Service objects. By doing so, the Service Locator can return various versions and flavors of the required Service objects. Thus, the dependent object does not need to use any explicit reference to any implementation of the Service object. However, the dependent object still needs to know about the Service Locator component.

COMPARISON

The two methods of passing the dependency to the object: one through constructors and the other through appropriate setter methods. As usual, both methods have their pros and cons.

Here are some of the advantages of using the constructor-based IoC:

• We can hide (or encapsulate) all your fields without having to expose them through setter methods.
• A constructor with a specific number of parameters gives you a clear indication of what it means to create an object.

On the other hand, the disadvantages with constructor-based IoC are:

• It has got too many parameters to be passed inside the constructor, that starts looking messy.
• The order of parameters becomes important.
• If, at the time of creating the object, if the programmer is not sure about the dependencies the object will take up, he may not be able to inject the dependency through a constructor.
• Constructors can suffer from classic inheritance problems when super class constructors do change or a sub-class is added. (LINK TO MY INHERITANCE VS COMPOSITION ARTICLE). Although, this is more of a problem in the OO domain, it is significant enough here to effect the success of IOC.

The dependency lookup concept works fine, but only if all the application modules are developed under the same hood and you have a thorough knowledge of every API of every component used in the application. If the programmer is developing a component for a third party, he  probably would not be going to know anything about the kind of service locator component that third party will use. Hence, this model might fail to work.