Understanding the Inversion of Control (IoC) Principle
Inversion of Control (IoC) is a programming principle that allows you to develop loosely coupled applications. As a developer or programmer, you must’ve heard about this software development term before. The simple intuition behind loosely coupled applications is to make applications scalable without affecting the main business logic.
Inversion of Control (IoC) is a concept inspired by loose coupling whereby objects define their dependencies through constructor arguments, setter methods, or through properties that are defined on the object instance.
To understand this concept better, let's take one real-life example:
Let’s assume that there is a patient suffering from viral fever, who went to a doctor for getting the proper medication. The doctor will give the patient a prescription based on its condition. Now, it’s the patient who needs to follow this prescription as the doctor is only prescribing the course of treatment. So, the patient is in control here.
In the other scenario, let’s assume the patient is suffering from a serious disease (COVID19 per se), who went to a doctor for getting the treatment. This time the doctor will instruct the patient to follow certain guidelines such as getting himself isolated, following the proper medication plan, taking the proper food as prescribed by the doctor, etc. It’s not up to the patient anymore! (I assume he or she wants to get better at the earliest) The doctor is in control here.
This, in simple terms, is called Inversion of Control (IoC).
To make it more relatable, let’s take one more example.
Let’s assume you’re a developer (or programmer) and you instruct the application (or the piece of code) to perform the task as you desire. You’re controlling the flow of execution of your application. (You can relate it with the Imperative programming principle). So, the developer is in control here. On the other hand, let’s assume you’re using a framework where the framework provides you a readymade template that decides the flow of execution. The framework is in control here. This is an Inversion of Control.
If you get through this line, I assume you must be looking for a practical (coding) example. So, let’s dive into it.
Let’s say you’re a client who wants an application that greets people in their own language. Let’s name that application as “Greeting Service Application”.
This Greeting Service App depends upon some helper classes (or dependencies) that will print a greeting message in different languages. For simplicity, I’m considering only 3 languages as follows:
- EnglishGreetingService.java — Greets a person in English
- FrenchGreetingService.java — Greets a person in French
- SpanishGreetingService.java — Greets a person in Spanish
Now, we’re going to make this application loosely coupled by using the IoC principle. To do that, we’ll make use of two entities:
- A Service Provider (an Interface)
- An Object Factory or POJO class — This is a template provided by the framework. Since we’re not using any framework in this yet! so I’ll hardcode this object factory for you.
Given below is the java code for the helper classes and the service interface.
We’re creating loosely coupled applications through interfaces. Read more on this here. This design pattern won’t confuse you if you’re well aware of the SOLID design pattern principles.
Here’s the code for our object factory (standard object template) and the main class.
You can read more about factory patterns by following this link. You can consider this object factory class as our standard template where the developer just specifies the object that the application depends upon.
In a nutshell, the Main Class (Greeting Service App) is dependent here upon 3 dependency classes (English/French & Spanish Greeting Service) and the entire application flow (creation & management of objects) is handled by the object factory. So, the Object Factory is in control.
You can find the complete application code on my Github link: https://github.com/SumitKumar30/Spring-NCU-2022.git
Stay tuned for more such articles. Happy Learning :)
