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

This article will explain in detail what are the principles and benefits of IOC in Spring. The content of the article is of high quality, so the editor will share it with you for reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

Seven principles of design pattern

Why would anyone say that design patterns are dead? because spring frameworks help you manage classes and objects, allowing you to focus on what you implement, not on design, when you write code. Let's first take a look at the seven principles of design patterns:

Open-closed principle

Principle of single responsibility

Dependence reversal principle

Principle of minimum knowledge

Interface isolation principle

Principle of synthesis / polymerization reuse

According to the principle of Richter substitution, subclasses can appear wherever the base class can appear.

Dependency inversion

Suppose we design a car: first design the wheels, then design the chassis according to the size of the wheels, then design the body according to the chassis, and finally design the whole car according to the body. Here there is a "dependence" relationship: the car depends on the body, the body depends on the chassis, and the chassis depends on wheels.

This kind of design looks fine, but the maintainability is very low. Suppose that after the design is completed, the boss suddenly says that according to the changes in market demand, he wants us to change the wheel design of the car to a larger size. Now we have a pain in the egg: because we design the chassis according to the size of the wheel, the design of the chassis has to be changed as soon as the size of the wheel is changed; also because we design the body based on the chassis, then the body has to be changed. in the same way, the car design has to be changed-almost the whole design has to be changed! Let's think differently now. We first design the general appearance of the car, then design the body according to the appearance of the car, design the chassis according to the body, and finally design the wheels according to the chassis. At this point, the dependency is reversed: the wheel depends on the chassis, the chassis depends on the car body, and the car body depends on the car.

The boss said that if we want to change the design of the wheel, we only need to change the design of the wheel, not the chassis, the body, the design of the car. This is to rely on the principle of inversion-the original high-rise buildings rely on the ground floor buildings "upside down" to the ground floor buildings rely on high-rise buildings. High-rise buildings decide what they need, and the bottom floor to achieve such needs, but the high-rise buildings do not care how the ground floor is achieved. In this way, there will not be the situation of "leading one to start the whole body".

Control inversion (Inversion of Control)

It is a kind of code design idea that relies on the principle of inversion. The specific approach is called dependency injection (Dependency Injection). In fact, these concepts will feel foggy for the first time. To put it bluntly

In order to understand these concepts, let's use the example of a car above. Only this time it was changed to code. Let's first define four Class, car, body, chassis, tire. Then initialize the car, and finally run the car.

Thus, in the first example above, the superstructure relies on the lower structure-- the constructor of each class calls the constructor of the underlying code directly. Suppose we need to change the Tire class to make it dynamic instead of being 30 all the time.

Since we have modified the definition of the tire, we need to make some changes in order to make the whole program work properly.

Just to modify the tire constructor, this design requires modifying the constructor of the entire upper class! In software engineering, such a design is almost unmaintainable-in an actual engineering project, some classes may be the bottom of thousands of classes. if we have to modify all the classes that depend on it every time we modify this class, then the maintenance cost of the software is too high. So we need to IoC, and the upper layer controls the lower layer, not the lower layer controls the upper layer. We use dependency injection (Dependency Injection) to implement control inversion. The so-called dependency injection is to transfer the bottom class as a parameter to the upper class to realize the "control" of the upper class to the lower class. Here we rewrite the definition of the car class using the dependency injection passed by the constructor.

Here we make the tire size dynamic again, and we need to modify it in order for the whole system to run smoothly.

You just need to modify the tire class, not any other upper class. This is obviously more maintainable code. Not only that, in practical projects, this design pattern is also conducive to the cooperation and unit testing of different groups: for example, if these four classes are developed by four different groups, as long as the interfaces are defined, four different groups can be developed at the same time without being restricted to each other. For unit testing, if we want to write a unit test for the Car class, we only need to Mock the Framework class to pass the Car instead of new all the Framework, Bottom, and Tire to construct the Car. Here we are using the constructor passed in the way of dependency injection. In fact, there are two other methods: Setter passing and interface passing. There is no more talk here, the core ideas are all the same, all in order to achieve control reversal.

Control inversion Container (IoC Container)

In fact, in the above example, the place where the code that initializes the car class occurs is the control inversion container.

Obviously you should have noticed that because of dependency injection, it is inevitable that a large amount of new will be written during initialization. Here the IoC container solves this problem. This container can initialize your code automatically. You only need to maintain a Configuration (xml can be a piece of code) instead of having to write that large piece of initialization code each time a car is initialized. This is the first benefit of introducing IoC Container. The second benefit of IoC Container is that we don't need to know the details when creating an instance. In the above example, when we manually create a car instance, it is new from the bottom to the top.

So much for sharing the principles and benefits of IOC in Spring. I hope the above content can be of some help to you and learn more knowledge. If you think the article is good, you can share it for more people to see.

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.