What is IoC
oc—Inversion of Control, that is, "inversion of control", is not a technology, but a design idea. In Java development, Ioc means handing over the object you designed to the container control, rather than the traditional direct control inside your object. How to understand Ioc well? The key to understanding Ioc is to clarify "who controls who, controls what, why is it reversed (if there is a reverse, there should be a forward rotation), and what aspects are reversed", then let's analyze it in depth:
Who controls who, controls what: In traditional Java SE programming, we create objects directly inside the object through new, and the program actively creates dependent objects; while IoC has a special container to create these objects, that is, the Ioc container comes from Controls the creation of objects; who controls whom? Of course the IoC container controls the object; what? That is, it mainly controls the acquisition of external resources (not just objects including files, etc.).
Why is it reversed, and which aspects are reversed: if there is a reverse, there will be a forward rotation. The traditional application is actively controlled by ourselves in the object to directly obtain the dependent object, that is, the forward rotation; while the reverse rotation is caused by the container to help create and inject dependent objects; why reverse? Because the container helps us find and inject dependent objects, the object only passively accepts dependent objects, so it is reversed; which aspects are reversed? The acquisition of dependent objects is reversed.
To illustrate with a legend, the traditional programming as shown in Figure 2-1, is to actively create related objects and then combine them:
Figure 2-1 Schematic diagram of traditional application
When there is an IoC/DI container, these objects are no longer actively created in the client class, as shown in Figure 2-2:
What can IoC do
IoC is not a technology, but an idea, an important principle of object-oriented programming, which can guide us how to design loosely coupled and better programs. In traditional applications, we actively create dependent objects inside the class, which leads to high coupling between classes and is difficult to test; with the IoC container, the control of creating and finding dependent objects is handed over to the container, and the container By injecting and combining objects, the objects are loosely coupled, which is also convenient for testing, which is conducive to functional reuse, and more importantly, makes the entire architecture of the program very flexible.
In fact, the biggest change that IoC 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 container to create and inject the resources it needs.
IoC embodies one of the principles of object-oriented design - the Hollywood law: "don't find us, we find you"; that is, the IoC container helps the object find the corresponding dependent object and inject it, rather than the object actively finding it.
IoC和DI
DI-Dependency Injection, that is, "dependency injection": the dependency between components is determined by the container at runtime. To put it figuratively, the container dynamically injects a dependency into the component. The purpose of dependency injection is not to bring more functions to the software system, but to increase the frequency of component reuse and build a flexible and extensible platform for the system. Through the dependency injection mechanism, we only need to specify the resources required by the target through simple configuration without any code, and complete our own business logic, without caring where the specific resources come from and who implements them.
The key to understanding DI is: "who depends on whom, why does it need to depend, who injects who, and what is injected", then let's analyze it in depth:
● Who depends on whom: Of course, the application depends on the IoC container;
● Why do you need dependencies: The application needs the IoC container to provide the external resources required by the object;
Who injects who: It is obvious that the IoC container injects an object of the application, the object that the application depends on;
● What to inject: It is to inject external resources (including objects, resources, constant data) required by an object.
What is the relationship between IoC and DI? In fact, they are descriptions of the same concept from different perspectives. Because the concept of inversion of control is rather vague (it may only be understood as the level of container control objects, it is difficult for people to think of who will maintain the object relationship), so the 2004 master Martin Fowler A new name is given: "dependency injection". Compared with IoC, " dependency injection" clearly describes "the injected object depends on the IoC container to configure the dependent object".
Note: If you want to have a deeper understanding of IoC and DI, please refer to a classic article "Inversion of Control Containers and the Dependency Injection pattern" by the master Martin Fowler, the original address: http://www.martinfowler.com/ articles/injection.html.
