Several Terms Related to Dependency Injection 😵
Around one year ago, I had written an article about dependency injection. Recently, I review again the dependency injection. Frankly, it is a wide field of knowledge. I bought a dependency injection book almost seven hundred pages, but I have still not read over yet… 😧 However, due to my work reason, either developing desktop application or web application both implement dependency injection pattern. And thanks to this design pattern, it makes multiple modules being loosely coupled, maintainable, and let us maintain the systems more smoothly.
If you have not yet read the previous article, check it out! :)
Speak to Dependency Injection, there are lots of terms and might confused the beginner.
Let’s look at this picture which I believe regarding DI it is a common picture to see.
📝Dependency Inversion Principle (DIP)
Dependency inversion principle is one of the rules in the SOLID. It states every entity should be dependent on abstractions and not on concretions. Based on Open-Closed principle viewpoint, there are two principles should be followed.
One is “High-level modules should not depend on low-level modules. Both should depend on abstractions.” and the other one is “Abstractions should not depend on details. Details should depend on abstractions.”.
Dependency inversion principle does not provide any implementation but it is a high-level guideline to design a better application.
📝Inversion of Control (IoC)
Inversion of Control is a design principle which it can achieve the loosely coupled among several applications. It lets the control being inverse, and the high-level module does no longer depend on low-level module anymore. Both of them depend on the abstraction, and the control is handled by the third party. The control here refers to the responsibility of a class has, like creating the dependent object.
📝Dependency Injection (DI)
Dependency injection is a design pattern and implements inverse of control principle and Dependency inversion principle. In practice, if we follow the dependency injection pattern, it makes the modules loosely coupled, the code being more reusable and applications being more maintainable.
The advantages of dependency injection would be much more apparently if the scenario is an application with multiples modules. But due to the limitations here, let’s take a smaller example to mimic dependency injection.
From the code below, we find out that Application class is dependent on WorkerDAO class. They are tightly coupled to each other.
Moreover, if WorkerDAO class instantiation is modified, or Application class needs more others similar functionalities as WorkerDAO, then the code is hard to maintain and reuse.
As the picture below, it depicts the relationship between the classes.
Let’s review again the dependency inversion principle. We should follow two points.
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.
If we follow dependency injection principle, and the structure would be like the picture below. Apparently, we do not need to concern about adding more services in the client brings out more troublesome or if the way of initiating the object is modified.
Thus, both client and service depend on abstractions. And client does not concern about initiating the objects anymore.
📝Inversion of Control Container(IoC Container)
There are several types of IoC Container third party, like Unity, Autofac, Ninject, Spring…etc. IoC Container framework is meant to manage object and inject service into client class. It can store all the mapping of interface and object, so if there are amount of modules needed the same services, IoC Container is a great way to manage all services and manage the lifetime of objects.
If we take Unity as our IoC Container, then it would be implemented as below.
Unity package provides IoC Container utility, and we can register the services to the container, and get the instance via resolve functionality.
There are several ways to register the services to the container, like configuration, configuration as code or auto-registration. The example above takes the configuration as code way. Usually, we would put them to the module start-up file. Means, all of the modules in the application can be injected the multiple services, and there is no need to initiate the service object.
Also, we can register the several services through the configuration, like json file or xml file. But comparing to configuration as code we can not correct it during the compiling time.
There are lots of terms and extending knowledge based on the principle. For example, Inverse of Control principle extends to many design patterns or methods, like service locator pattern, delegates, event, dependency injection…etc. All of these practical ways are meant to make the application more flexibility and easily maintain.
Although it is hard to understand just going through the books or some articles, we still can try to use simple way realize it or seize the chance of facing the enterprise applications then we would much more understand several design pattern usage! (๑و•̀ω•́)و
