Another short departure from the inner urges of design guru is what resulted in this blog post about Inversion of Control (IOC)/Dependency Injection (DI). I have decided to switch between technical and design oriented topics in my blog post from this point.

The reason why I put the word “Manager” in the topic is to stave off from technical nitty-gritty details like reflection etc. (internet is awash with such articles of that nature), rather get into the higher purpose and object oriented motivation behind the IOC/DI.

What is IOC/DI?

Predominantly software systems’ implements, a flow of control from the top to bottom or higher level module to lower level module. A simple real world example can throw some light: Let’s take a Car class instance and, Car class determines the composed object instances (like Engine, Door etc.,) life time and scope. This principle is called composition  in object oriented world. And in parallel to composition, there is a similar principle, called as aggregation. 

Aggregation is where the passengers can come and go but passenger outlives the car. But the engine cannot outlive the car. Also within the context of car, passenger (which is typically a polymorphic interface) is injected through the constructor of a car class. This way, again, within the context of the class, there is a dynamism introduced and this dynamic state behavior which is practically controlled by an external entity, which here happens to be a low level module, can be broadly described as inverting the flow of control. Now we have justified the word “IOC”. “Dependency Injection” (DI) can be justified by claiming that the passenger code is being injected from an external entity.

Why IOC/DI?  – 

This principle allows the lower level module to control the behavior and state of the class dynamically without changing the existing piece of code. This way it honors the Open/Closed Principle.