1. If there is no IOC, what are the problems in our project maintenance? 2. 4. What problems does AOP solveCopy the codeHello everyone, I am the most generous small ears in 49 cities.
Today let’s talk about IOC and AOP of Spring in plain English.
1. If there is no IOC, what problems may exist in our project maintenance
If a ServiceA class calls a method of another ServiceB class, we need to new an object of class ServiceB in the method of class ServiceA.
If you now have dozens of classes that need a ServiceB method, then you need to create a ServiceB object in each of the dozens of classes.
One day, the business changes, you write a new class ServiceC, and the class ServiceB is obsolete. You’d have to change the code for “ServiceB b= new ServiceB ()” to “ServiceC c= new ServiceC ()” in dozens of classes that previously called ServiceB. What if ServiceC is obsolete one day, and dozens of ServiceD classes now require ServiceD methods? Also, what if you don’t complete the substitution? For example, if you miss a point, the project runs and then calls the method of the object ServiceC, but the ServiceC logic is obsolete.
2. What problems has the IOC solved
Spring’s IOC mechanism was born out of this complete coupling of classes and classes.
If your project now includes the Spring framework, and you still have the same requirement that you call a ServiceB method in ServiceA, your code will look like this.
You create an interface, ServiceB, and then create an implementation class for it, ServiceBImpl. Inject the interface ServiceB into the ServiceA.
At this point, when your project starts, the Spring container uses Java’s reflection technology underneath to scan the beans in your project.
It first finds that the class ServiceA references the interface ServiceB, and then it finds out who implements the interface ServiceB, and it finds that the class ServiceBImpl implements the interface ServiceB, and based on this dependency, It instantiates a ServiceBImpl object in class ServiceA.
What are the benefits of this? If the ServiceBImpl class is deprecated and ServiceA needs to call my new ServiceC method, would the @autoWired private ServiceB b code in class A need to be changed? I don’t need to. I just need the new ServiceC to implement the ServiceB interface, so that the Spring container generates the ServiceC object inside class A.
This way, if dozens of classes reference the interface ServiceB, I just need to make ServiceC implement the interface ServiceB, and I don’t need to change the relevant reference blocks in dozens of classes.
In other words, IOC, also known as dependency injection, means that the Spring container uses reflection technology to create beans according to annotations or configuration files, and then instantiates corresponding objects according to dependencies and import relationships between beans, thus achieving complete decoupling between classes. You create an interface, and then you have an implementation class A, and the other classes reference the logic in A, and then A becomes obsolete, and you create A class B that implements the interface, and that’s all you have to do, instead of having to change the code from “A A = new A()” to “B B = new B()” in each class.
- Without AOP, what’s wrong with our project maintenance
After IOC, let’s talk about AOP.
A long time ago, when I was in college, the teacher taught JSP+Servlet project, every time to do add, delete, change and check, a method had to write a fixed code at the beginning of “open transaction” and so on, at the end of the place had to write a fixed code “submit transaction” and so on.
God, if you think about it, there’s no beauty in all that code.
For another example, the company now lets you create a log module, which records all additions, deletions and changes in a table. When you look at the requirements, it’s easy. In order to implement the function quickly, you write A bunch of fixed code behind each method, call method A to get the current user, and then call Dao A to write the data to the log table.
And then you wrote the project and went online. After A few days, methods A and Dao A are obsolete and you have to call methods B and Dao B! So what do you do? Can only go to a method to change the code! But what if you miss a change, there will be problems after the online ah!
- What problems does AOP solve
Based on the problem of repeating code above, AOP was born.
Now we write code using the Spring framework. When we add, delete, or modify methods, we simply add a transaction annotation @transcational and write our own business logic. In fact, underneath the Spring container, it uses dynamic proxy technology to generate a dynamic proxy class with @transcational annotations on our methods. This dynamic proxy class implements all the methods of your class.
The proxy class weaves enhanced code into each implemented method. For example, if method A of class A has A transaction annotation @transcational, method A of ProxyA, which is generated by dynamic proxies, will weave A fixed code at the beginning of the method “open transaction” and so on, and A fixed code at the end “submit transaction”.
In this way, you can avoid the repetitive “open transaction” and “commit transaction” blocks of code that you saw in the original JSP + Servlet project.
The same principle applies to project logging with AOP, which uses dynamic proxy techniques to generate a dynamic proxy class of classes that implements all of your class’s methods and then weaves enhanced code into each method based on your annotations. Thus avoiding a lot of duplicate code in the project, a change will have to change dozens of methods of the problem.
End
Copy the codeAuthor brief introduction: bold small ear, a bold programmer. I want to work with you in the world of technology and look at the world from the perspective of technology. Welcome to scan the qr code below, continue to pay attention to a large wave of original series of articles on the way
