Shulou(Shulou.com)06/03 Report--

Today, I will talk to you about the example analysis of the interpretation of IOC and DI in the spring framework, which may not be well understood by many people. in order to make you understand better, the editor has summarized the following content for you. I hope you can get something according to this article.

1. What is IOC

IOC-Inversion of Control, or "inversion of control", is not a technology, but a design idea. In Java development, Ioc means handing over your designed objects to the control of the container, rather than the traditional direct control within your objects.

How to understand Ioc well? The key to a good understanding of Ioc is to make clear "who controls whom, controls what, why is a reversal (if there is a reversal, there should be a positive reversal), and which aspects are reversed." then let's make an in-depth analysis:

Who controls who and what: in traditional Java SE programming, we create objects directly inside objects through new, and the program takes the initiative to create dependent objects; while IOC has a special container to create these objects, that is, the IOc container controls the creation of objects instead of explicitly using new;. Who controls who? Of course, it is the IOC container that controls the object; controls what? That is, it mainly controls the acquisition of external resources and life cycle (not only objects but also files, etc.).

Why is the inversion, and which aspects are reversed: where there is a reversal, there is a positive reversal, and the traditional application is controlled actively by ourselves in the object to directly obtain the dependent object, that is, the forward reversal; while the inversion is helped by the container to create and inject the dependent object; why the reversal? Because the container helps us find and inject the dependent object, the object only passively accepts the dependent object, so it is reversed; which aspects have been reversed? The acquisition of dependent objects has been reversed.

To illustrate with a legend, the traditional program design, as shown in figure 1, takes the initiative to create related objects and then combine them:

Figure 1 traditional application structure diagram

When you have the container for IOC, you no longer take the initiative to create these objects in the client class, and the structure diagram of the program is shown in figure 2:

Figure 2 Program structure with IOC Container figure 2. What can IoC do?

IOC is not a technology, but an idea, an important rule of object-oriented programming, which can guide us to design loosely coupled and better programs. In traditional applications, we take the initiative to create dependent objects within classes, resulting in high coupling between classes and difficult to test.

With the IOC container, the control of creating and finding dependent objects is given to the container, and the container injects composite objects, so the objects are loosely coupled, which facilitates testing, facilitates functional reuse, and, more importantly, makes the whole 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, there has been a "master-slave transposition" change. The application is originally the boss, and it takes the initiative to get any resources, but in the idea of IOC/DI, the application becomes passive, passively waiting for the IOC container to create and inject the resources it needs.

IOC is a good embodiment of one of the object-oriented design principles-the Hollywood rule: "Don't look for us, we'll find you"; that is, the IOC container helps the object find the corresponding dependent object and inject it, rather than let the object find it actively. (search the official account Java bosom friend, reply "2021" and send you a treasure book of Java interview questions.)

3. IOC and DI

DI-Dependency Injection, or "dependency injection": dependencies between components are determined by the container at run time, that is, a dependency is dynamically injected into the component by the container.

The purpose of dependency injection is not to bring more functions to the software system, but to increase the frequency of component reuse and to build a flexible and scalable platform for the system. Through the dependency injection mechanism, we only need to specify the resources needed by the target and complete our own business logic through simple configuration without any code, without caring about where the specific resources come from and by whom.

The key to understanding DI is: "who depends on whom, why, who injects whom, and what?" let's take a closer look at it:

Who depends on whom: of course, the application depends on the IOC container

Why you need dependency: the application needs the IOC container to provide the external resources that the object needs; who injects who: it is obvious that the IOC container injects an object that the application depends on; what is injected: the external resources (including objects, resources, constant data) needed to inject an object.

What does IOC have to do with DI? In fact, they are described from different angles of the same concept, because the concept of control inversion is relatively vague (it may only be understood as the container control object level, it is difficult to think of who will maintain the object relationship), so in 2004, the master Martin Fowler gave a new name: "dependency injection". Relative to IOC, "dependency injection" clearly describes "injected object dependency IOC container configuration dependency object".

Read a lot of articles on the understanding of Spring's Ioc, many people's explanations of Ioc and DI are obscure, anyway, it is a kind of inexplicable, unclear feeling, after reading, there is still a confusion. After reading this technical man's blog, there is a kind of suddenly enlightened research. He clearly explained every word in IOC (inversion of Control) and DI (dependency injection). After reading, it gives people a feeling of sudden enlightenment. I believe that it should be very helpful for beginners of Spring framework to understand IOC.

4. The significance of IOC and DI

In normal Java application development, we need at least two or more objects to work together to achieve a certain function or business logic. When Spring is not used, each object uses syntax like new object () to create the cooperative object when it needs to use its cooperative object or dependent object. This cooperative object is created on its own initiative. The initiative of creating cooperative objects is in their own hands, and they will take the initiative to create which cooperative objects they need, and the initiative and timing of creating cooperative objects will be controlled by themselves. and this will make the degree of coupling between objects high, An object needs to use cooperative object B to accomplish a thing together, A to use B, then A has a dependence on B, that is, there is a coupling relationship between An and B. And it's tightly coupled.

After using Spring, it is different. The work of creating cooperative object B is done by Spring. Spring creates the B object and then stores it in a container. When An object needs to use B object, Spring takes out the B object that A wants to use from the container where the object is stored, and then gives it to An object for use. As for how and when Spring creates that object, Object A doesn't need to care about these details (I don't care when or how you were born, just work for me). After A gets the object B given to us by Spring, the two can work together to finish the work to be done.

So control reversal IOC (Inversion of Control) means that the control of creating objects is transferred. In the past, the initiative and timing of creating objects were controlled by themselves, but now this power is transferred to a third party, such as the IOC container, which is a factory dedicated to creating objects. It gives you whatever objects you want. With the IOC container, the dependency changes. The original dependencies are gone, and they all rely on the IOC container to establish the relationship between them through the IOC container.

DI (dependency injection) is actually another term for IOC. DI was first proposed by Martin Fowler in a paper at the beginning of 2004. He concluded: what has been controlled has been reversed? Is that the way of getting dependent objects is reversed.

Recommended article > > [training project] ERP system based on SpringBoot, with its own functions of purchase, sale and storage, finance and production.

> > share a set of enterprise middle and background open source projects based on SpringBoot and Vue, the code is very standard!

> > can make money, open source SpringBoot Mall system, super-complete, super beautiful!

After reading the above, do you have any further understanding of the sample analysis of IOC and DI interpretations in the spring framework? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.