How to understand IoC/DI
To understand the above two concepts, we must understand the following questions:
- Who are the participants?
- Dependency: Who depends on whom? Why do you need a dependency?
- Inject: Who injects into whom? What exactly is injected?
- Inversion of Control: Who Controls Who? Control what? Why is it called reversal (if there is reversal, there should be forward rotation)?
- Are Dependency Injection and Inversion of Control the same concept?
Let's briefly answer the above questions, and if these questions are understood, IoC/DI will also be understood.
(1) Who are the participants:
There are generally three parties involved, one is an object; one is the container of IoC/DI; the other is an external resource of an object.
To explain the term again, an object refers to an arbitrary, ordinary Java object; the container of IoC/DI simply refers to a framework program used to implement the function of IoC/DI; the external resource of an object refers to the object Required, but obtained from outside the object, are collectively referred to as resources, such as: other objects required by the object, or file resources required by the object, and so on.
(2) Who depends on whom:
Of course, an object depends on the container of IoC/DI
(3). Why does it need to depend on:
The object needs the container of IoC/DI to provide the external resources required by the object
(4) Who injects into whom:
It is obvious that the container of IoC/DI injects an object
(5) what exactly is injected:
It is to inject external resources required by an object
(6) who controls who:
Of course, it is the container of IoC/DI to control the object
(7) what to control:
It is mainly the creation of control object instances
(8) why it is called inversion:
Reversal is relative to positive, so what is positive? Consider an application in a normal situation, if you want to use C inside A, how would you do it? Of course, it is to directly create an object of C, that is, to actively acquire the required external resource C in class A, which is called forward. So what is the reverse? That is, class A no longer actively obtains C, but passively waits, waiting for the IoC/DI container to obtain an instance of C, and then injects it into class A in reverse.
To illustrate with a legend, first look at the schematic diagram of the conventional class A using class C when there is no IoC/DI, as shown in Figure 7:
Figure 7 Schematic diagram of conventional A using C
When there is an IoC/DI container, class A no longer actively creates C, as shown in Figure 8:
Figure 8 Class A no longer actively creates C
Instead, it waits passively, waiting for the IoC/DI container to obtain an instance of C, and then injects it into class A in reverse, as shown in Figure 9: 
Figure 9 Schematic diagram of the program structure after the IoC/DI container
(9) Are dependency injection and inversion of control the same concept?
According to the above description, it should be seen that Dependency Injection and Inversion of Control are different descriptions of the same thing. In one respect, they describe different angles. Dependency injection is described from the perspective of the application, and it can be described completely: the application relies on the container to create and inject the external resources it needs; while the inversion of control is described from the perspective of the container, and the complete description is: the container Control the application, and the container injects the external resources required by the application into the application in reverse.
(10) To summarize:
In fact, the biggest change that IoC/DI brings to programming is not from the code, but from the idea, the change of "master-slave transposition" has taken place. The application is originally the boss, and it takes the initiative to acquire any resources, but in the IoC/DI idea, the application becomes passive, passively waiting for the IoC/DI container to create and inject the resources it needs.
Such a small change is actually a big progress in programming thinking, which effectively separates the object and the external resources it needs, making them loosely coupled, which is conducive to functional reuse, and more importantly, the entire system of the program. The structure becomes very flexible.