IOC

The article will also be published on the official account of the same name, “Makesi”, a suitable official account of the student Party! Take you into the world of programming easy to understand!

1. What is IOC

IOC (Inversion of Control) is a design principle used in object-oriented programming to reduce coupling between computer code. One of the most common is called Dependency Injection, or DI, and another is called Dependency Lookup. With inversion of control, when an object is created, it is passed a reference to the object on which it depends by an external entity that regulates all objects in the system. In other words, dependencies are injected into objects.

Inversion of control is simply: “You don’t need to come to me, I’ll come to you.”

For example: now we need objects of class B in class A

  • == The traditional way == : is to create A new object of class B in class A

  • == Use IOC technology == : At this time, in our class A, we only need to define an object of class B, and do not need to new it in the traditional way. It is externally through the IOC container that pairs class B

    It comes out like new, and then it’s injected into class A. So, whatever object we need, we can grab it in the container.

Either way, I give the IOC container the power THAT I have (the ability to create objects on my own initiative), so that we no longer have to worry about which objects to create.

2. DI (Dependency Injection)

Those of you who know Spring know that the core mechanism of Spring is DI. But it’s also important to know that IOC is not unique to Spring.

Two ways to inject

  • Setter mode (pass value mode)
  • Constructor mode (reference mode)

The time of dependency injection

  • The first time we get a Bean from the IOC container via getBean, dependency injection is triggered
  • When we configure the Bean properties in the Spring configuration file.xmllazy-initProperty, that is, lazy loading is turned off, and the container instantiates the bean when it registers, triggering dependency injection

PS: Lazy loading means that when our container registers the bean, it does not create the object and only loads the object when it is actually called.

  • Advantages: Objects are created only when they are in use, saving resources.
  • Disadvantages: Not conducive to early detection of errors.

3. What problems has the IOC solved?

1. Reduced coupling or dependence between objects

  • We all know that it’s important to judge how good an application is, how coupled it is, because it relates to how maintainable your application is. So IOC optimizes this.

2. Better management of resources

  • When you need to use an object that implements a class, you can just pull it out of the container and easily implement a singleton.

The following details about IOC:

LAN saw a vivid example on CSDN during his early study, which, in my opinion, showed us the benefits of inversion of control.

Here are some vivid examples:

Suppose we design a car: design the wheels first, 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 comes a “dependency” relationship: the car depends on the body, the body depends on the chassis, and the chassis depends on the wheels.

At this point, if our immediate boss asks us to change the wheels a size larger, then this is the trouble, according to the wheels tailored chassis, as well as the body and the car. They’re all gonna have to be redesigned. Such maintainability is very low!

Let’s think another way. 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 dependence is reversed: the wheels depend on the chassis, the chassis depends on the body, the body depends on the car.

After that, if you wanted to make the wheel a size bigger, you could just change the design of the wheel instead of changing all the parts.

This is a good example of the inversion principle.

Our IOC is an approach to code design based on the dependency inversion principle, followed by DI (dependency injection). The relationship between the three is:

Finally, let’s take an example to get to the bottom of IOC

For example, you now have an entity class for User, and then you need to develop the User using the Service and Dao layers

First our traditional way:

At this point we can see that the Dao layer has only one implementation class, so there is really no difference. But if the Dao layer has an implementation class. For example, in the Service layer, to operate on the Dao layer, we divide users into two categories, one is employees, one is leaders. At this point, the Dao layer needs an additional implementation class. At this point, when we call the Dao layer, we need to change the code in the Service to new the object we want.

Then we use IOC, giving control to the IOC container to manage and get it from the container when needed

This way, we don’t have to write a lot of new in the Service to create the object we depend on, and we just need to maintain the configuration file (.xml file) in the middle, as anyone who has learned from Spring knows. This also greatly reduces our code amount!

At the end of the day, just remember, what is inversion of control?

Essentially giving control of the built-in objects to the container.

END

Finally, I hope this article can help you. If there are any mistakes in the article, please correct them!