Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

What are the principles of DI/IOC and AOP in the foundation of Spring

2025-04-12 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Internet Technology >

Share

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

What this article shares with you is about the principles of DI/IOC and AOP in the foundation of Spring. The editor thinks it is very practical, so I share it with you to learn. I hope you can get something after reading this article.

Introduction to the Core of Spring Framework

DI (Dependency Injection), dependency injection, and another concept we often hear, IOC (inversion of Control), actually achieve the same function in the final analysis, but the same function is explained from a different point of view. Here the blogger does not go to too much discrimination, there are a lot of explanations on du Niang. What we need to know is what dependency injection is and why. To understand these two points, I think the study of Spring is ideologically correct.

When there is no use of Spring, that is, when there is no dependency injection, it is difficult to achieve functional cooperation between classes of java applications. If a class (A) needs to rely on the cooperation of another class (B), it needs to actively create a class B object in Class A. In order to use class B methods to complete the function (let's not worry about static methods and so on here). This is tantamount to class A being responsible for the management of the entire life cycle of class B objects.

In the case of extreme simplicity, there seems to be no problem with new objects of another class in one class, but the cooperative relationship between complex application classes and classes is often multilateral, and we do not know how many alternative objects the implementation of a class will rely on to collaborate, so creating objects in the class and managing the entire life cycle of objects will result in high coupling and unimaginable complexity of the code.

Then, just imagine, if we can leave the life cycle of an object to a third-party component to manage, and when a class needs another object, the third-party component will create it directly, so that the class can only focus on the implementation of its own function, without having to manage the life cycle of other class objects, so that the function of the class is much simpler. Yes, you must have understood that Spring (container) is this third-party component.

We just need to tell Spring which objects need to be managed, regardless of how the Spring framework creates objects. In this way, when a class A needs a class B object, if class B has been declared to be managed by the Sping container, then when the program runs to class An and needs class B, the Spring container injects the class B object into class A to help complete the business function. Through dependency injection by third-party components, objects no longer need to create and manage class-to-class dependencies on their own.

There are also many ways to create dependency injection, such as interface injection, constructor injection, setter method injection, and so on. At this point, you should have a more straightforward understanding of dependency injection. As for why dependency injection is necessary, it has been made clear that in order to reduce the coupling between components in the code, let's use a simple example to intuitively feel the benefits of dependency injection over managing objects--

Public class Man implements Human {

Private QQCar car

Public Man () {

This.car = new QQCar ()

}

@ Override

Public void xiabibi () {

}

Public void driveCar () {

Car.drive ()

}

}

There are two implementations of the interface Car: Mercedes-Benz and QQ. In the above code with high coupling between Man and QQCar. the old driver only creates a QQ object through the constructor, so he can only drive a QQ, so what if the old driver wants to drive a Mercedes-Benz? do you want him to recreate the object of the Mercedes-Benz? There seems to be nothing we can do about such highly coupled code, so let's improve the above code by injecting objects:

Public class Man implements Human {

Private Car car

Public Man (Car car) {

This.car = car

}

@ Override

Public void xiabibi () {

}

Public void driveCar () {

Car.drive ()

}

}

According to the polymorphic characteristics, the above code shields the specific object implementation by injecting the constructor interface, so that the old driver can drive whatever car he wants. This is the benefit of dependency injection.

AOP (Aspect Oriented Programming), aspect-oriented programming. In daily development, when we complete a business function, we write a pile of code, and when we finally optimize the code, we find that the code that really completes the business may only have two sentences, and the rest is not very relevant to that part of the business. the code that is just to implement a certain technology can be extracted, so naturally, we will extract it into a tool class. In this way, you only need to call the tool method to ok where it is used.

Let's stand a little higher and see that the functional components of each business module not only complete the relevant business functions, but also involve additional operations such as logs, transactions, security control and so on. These are not the core functions of the module, but they are indispensable. If these additional functions are added to the code, it is too repetitive for each component of the business system, and it makes the business code look confusing and not pure enough. At this point, you ask God, can you let your business code focus only on the implementation of the business, regardless of logs, transactions and other irrelevant things? Oh, God said no problem, so there is AOP.

If the purpose of dependency injection is to keep the components that cooperate with each other in a loosely coupled state, AOP is to separate functions throughout the application to form reusable components. Generally speaking, logs, transactions and other components can be reused. We can extract the log, transaction, security and other functional code scattered throughout the business code into a separate tool component, declare it as a functional aspect in the configuration of Spring, and then tell Spring where and when you want to use these reusable components. This is my simple interpretation of aspect-oriented.

These are the principles of DI/IOC and AOP in the foundation of Spring. The editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

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.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Internet Technology

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report