Introduction to IOC and AOP

IoC control inversion, also known as dependency inversion. The code does not directly connect to objects and services, but describes in the configuration file which component requires which service. The container is responsible for linking these together. In traditional development, always the keynote side must actively integrate the tuned side during the coding period, and the IOC realizes a more similar, the tuned side in the run process and then according to the configuration information to match the keynote side.

Both of these design patterns are implemented in Java using reflection.

The core benefit of these two design patterns is that they provide a very flexible component integration approach, where developers are free to assemble components, develop in-between interfaces, add packaging or decorations at will, and so on, so that the parts of the business logic can be isolated, Thus, the coupling degree between the parts of business logic is reduced, the reusability of the program is improved, and the efficiency of the development is improved.

After spring, what do you do with it? It's the business class. When a ClassA object is needed, the spring IOC container is created to create the ClassA object, which is then injected into the business class where it is needed. This shows the meaning of control inversion. That is, creating this ClassA object is actively created by the business class and changed to passively accept the injection of the spring IOC container.

This kind of thought is the aspect-oriented thought, it is actually a complement to the object-oriented thought.

Introduction to IOC and AOP