1. Inversion of Control (IOC)
To understand Inversion of Control (Inversion of Control), I think it is necessary to understand an important idea of software design: Dependency Inversion Principle.
Scenario:
Suppose we design a car: first design the wheels, then design the chassis according to the wheel size, then design the body according to the chassis, and finally design the entire car according to the body. Here is a "dependency" relationship: cars rely on the body, the body depends on the chassis, and the chassis depends on the wheels.
This design seems to be no problem, but the maintainability is very low. Suppose that after the design is completed, the boss suddenly said that according to the changes in market demand, we should change the design of the wheels of the car by one size. This time we are painful: because we design the chassis based on the size of the wheels, the design of the chassis must be modified if the size of the wheels is changed; also because we are designing the body based on the chassis, the body must also be modified, the same The car design must also be changed-almost the entire design must be changed! Let's change our thinking 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 time, the dependency is reversed: the wheels depend on the chassis, the chassis depends on the body, and the body depends on the car. 
At this time, if the boss wants to change the wheel design, we only need to change the wheel design, without moving the chassis, body, or car design. This is to rely on the principle of inversion.
The principle of reliance on inversion:
the original high-rise building depends on the low-level building "upside down", and the low-level building depends on the high-rise building. The high-rise building decides what it needs, and the bottom layer realizes such a requirement, but the high-rise building does not care how the bottom layer is realized. So there is no case in front of "pull launched a whole"
Inversion of Control:
The idea is to rely on the principle of inversion of a code design, specific methods to achieve the so-called dependency injection (Dependency Injection)
Dependency Injection:
is the underlying The class is passed into the upper class as a parameter to realize the "control" of the upper class to the lower class.
Inversion of control container :
The code is initialized automatically, only a Configuration, XML or @Autowired needs to be maintained, instead of using the new keyword to initialize each time, we don’t need to understand the details when creating an instance, and finally hand over all the instances we create to control Reverse container management.
Spring provides the following two different types of containers:
| container | description |
|---|---|
| Spring BeanFactory | It is the simplest container and provides basic support for DI |
| Spring ApplicationContext | The container adds more enterprise-specific functions |
The ApplicationContext container includes all the functions of the BeanFactory container, so it is generally recommended to exceed the BeanFactory. BeanFactory can still be used for lightweight applications such as mobile devices or applet-based applications.
A Spring Bean
bean is an object that is instantiated, assembled, and managed by the Spring IoC container.
2. Aspect-oriented programming (AOP)
scenario: For
example, we go to the bank to check the balance, withdraw money, and deposit money. Before performing these three operations, we need to verify our identity. After the identity is verified, we will perform specific operations. , We need to add authentication code in each business process. If the logic of identity verification changes, relevant places need to be adjusted, business complexity increases, and maintainability decreases. To solve this problem, we can define identity verification as a horizontal business, encapsulate it into a reusable module, and use aspect technology Use it where you need it.
Definition:
Object-oriented programming defines vertical business, and AOP is a supplement to object-oriented and defines horizontal business. Aspect-oriented encapsulates the functions that span multiple businesses and multiple calls into a reusable module, named the aspect, and then uses this aspect-oriented technology to apply it where needed, without modifying the original business Logic, reduce intrusiveness, achieve the purpose of simplifying business processes, enhancing methods and improving development efficiency, such as logging, declarative transactions, security, and caching.
The types of notifications
Spring can use the five notification tasks mentioned below:
| Notice | description |
|---|---|
| Advance notice | Before a method is executed, the notification is executed. |
| Post notification | After a method is executed, the notification is executed regardless of the result. |
| Notify after return | After a method is executed, the notification can only be executed when the method completes successfully. |
| Notify after an exception is thrown | After a method is executed, the notification can only be executed when the method exits and throws an exception. |
| Surround notification | The notification is performed before and after the suggested method call. |
Implementing custom aspects
Spring supports @AspectJ annotation style methods and pattern-based methods to implement custom aspects.
| method | description |
|---|---|
| XML Schema based | Aspects are implemented using conventional classes and configuration-based XML. |
| @AspectJ based | @AspectJ refers to a declarative style as regular Java class annotations with Java 5 annotations. |