Inversion of Control (IOC) and Hollywood Principle

Hollywood Principle is a design principle, stated as "Don't call us, we'll call you" is closely related with "Inversion of Control" Hollywood calls Actors when they need them instead of actor reaches Hollywood.

#Dependency Injection (DI)

Dependency Injection is a software design technique in which the creation and binding of dependencies are done outside of the dependent class. Dependencies are provided already instantiated and ready to be used, hence the term “injection”; in contrast to the dependent class having to instantiate its dependencies internally, and having to know how to configure them, thus causing coupling.

·???????? High-level modules should not depend on low-level modules. Both should depend on abstractions.

·???????? Abstractions should not depend on details. Details should depend on abstractions.

#Inversion of Control (IOC)

Inversion of Control is a design principle that inverts the flow of control in a program by decoupling components, making them more flexible and easier to maintain. In a traditional approach, high-level components are in control of the flow and call low-level components. With IoC, this control is inverted, and low-level components are responsible for the flow, allowing high-level components to focus on their core functionalities.

Benefits of IoC: Decoupling, No change of unit test when implementation changes, Scalability, Reusability

Lets try to understand with an Example:

We have a PaymentService class(A High Level Class) that depends on a PaymentProcessor class called "PaypalPaymentProcessor" (Low Level Class). The PaymentService creates object of the PayplePaymentProcessor class and control flow.

What if in future we need to use a different payment processor? or need to use the payment processor that the client wants?

If we want to keep this design we will need to modify this PaymentService1 class which will break "Open Close Principal" (SOLID)

Using "Inversion of Control" design principle we can write the class in a way so that we need to touch the code of this class when we want to switch a different payment processor or support multiple payment processor.

Lets define an interface IPaymentProcessor:

Lets look at our payment processors. ?

?

Now how we create the objects of these concrete classes of payment processor?

We can use Factory class (Factory Design Pattern) like below:

Driver class:

The commented lines from 11-12 can be used instead of line 8, which will be Dependency Injection through setter method injection (Strategy Design Pattern)

Conclusion: If you are still here, you can understand that this Article is an extension of my previous Article "Programming with Interfaces" :-)