Inversion of Control: part 1

Many of us including myself get puzzled when hear the word "Inversion of Control" for the first time. In real scenario, when you go to the bar and ask for a beer without specifying type of beer you like and still you get the beer from bartender, then there is a reverse of control. you can clearly see what part of aspect of control is being inverted; your control of specifying which type of beer you want has been shifted to bartender. Another example, well known Hollywood principle: "Don't call us, we'll call you".

One final real life case, in your company, you or colleagues may often have to travel around the country. So you need to know how to contact and communicate with your airline agent and cab agent designated by your company. Providing your destination, date and time information, your airline agent will be able to confirm for your flight and deliver you a ticket. Similarly, contacting with cab agent, you will be able to schedule cab for pick up/ drop off service.

One day your company decided to use go with new agents for both airline and cab service. Those new agents have completely different protocol how you contact and confirm your flights and cab. let's say they are all web-based while previous agents where phone-based. Now, you and your colleagues have to relearn all those protocol, which could very expensive process for the large company.

Owing such fact, company initiated an administration department to handle flights and cab reservations. Such department provided you with IVR system where you provide destination, date and time information and system is able to confirm you flight, schedule cab and deliver your ticket. So, if company decided to use any other agencies in the market, your aspect of way of communicating remains unchanged. Administrative department is the one responsible for adjusting such changes and even reprogramming IVR system so that you don't have to be aware of agency-based protocol.

I hope, by now, those real life scenarios should have given you the sense of Inversion of Control. For me, I see IoC as a shifting of some of your responsibility to someone else so that you can focus more on your actual goal. If your goal is to built a house, you shouldn't be worried about manufacturing hardwares and materials needed to built the house. They should be provided to you through some channels when you need them. Now, let's look how IoC could be a crucial design principle in context of software development.

public class CameraMan {

StillCamera sCamera;

public void shoot() {

sCamera = new StillCamera();

sCamera.action();

}

}

public class StillCamera{

public void action() {

System.out.println(“ take Picture");

}

}

In above two classes, see how class CameraMan is dependent to class StillCamera. if you want CameraMan to shoot a picture, CameraMan has to construct a StillCamera first. Then work on his goal, shooting the picture. To make more complex, if you want CameraMan to shoot the video, CameraMan has to learn how to construct videoCamera then after constructing one, will focus on his goal. In short, StillCamera class is tightly coupled with CameraMan class, resulting non-reusable components.

contd..

.