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

What is the working principle of Spring, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain in detail for you, people with this need can come to learn, I hope you can gain something.

The skeletal structure of Spring

Figure 1. Overall architecture diagram of the Spring framework

As you can see from the figure above, there are only three core components in the Spring framework: Core, Context, and Beans. They build the skeletal structure of the entire Spring. Without them, there can be no upper-level features such as AOP, Web and so on. The following will mainly analyze Spring from these three components.

The Design concept of Spring

The previous introduction of the three core components of Spring, if you choose the core among them, it will be Beans components, why do you say that, Spring is actually Bean-oriented programming (BOP,Bean Oriented Programming), Bean is the real protagonist in Spring.

Bean plays the same role in Spring as Object means to OOP. Without the concept of object is like without object-oriented programming, there is no meaning of Spring without Bean in Spring. It's like a show where the stage is ready but there are no actors. Why the role of Bean is Bean or why it is so important in Spring is determined by the design goal of the Spring framework, why Spring is so popular, and why we use Spring. Think about it, you will find that Spring solves a very critical problem that allows you to transfer the dependencies between objects to be managed by configuration files, that is, his dependency injection mechanism.

Its design strategy is completely similar to the design concept of Java to achieve OOP, of course, the design of Java itself is much more complex than Spring, but it is to build a data structure, and then design its living environment according to this data structure, and let it move constantly according to certain rules, and design a series of information exchange with the environment or with other individuals in their non-stop movement.

How core components work together

Bean is a key factor in Spring, so what is the role of Context and Core? If Bean is compared to an actor in a performance, then Context is the stage background of the performance, and Core should be the prop of the performance. Only when they are together can they have the most basic conditions to put on a good show. Of course, there are the most basic conditions that can not make the performance stand out, and the programs he performs are wonderful enough, which are the features that Spring can provide.

We know that Bean wraps Object, and Object must have data. How to provide a living environment for these data is the problem that Context wants to solve. For Context, he is to discover the relationship between each Bean, establish this relationship for them, and maintain this relationship. So Context is a collection of Bean relationships, which is also called the Ioc container. Once the Ioc container is created, Spring can work for you. So what are the opportunities for Core components to show their talents? In fact, Core is a series of tools needed to discover, establish, and maintain the relationship between each Bean. From this point of view, the Core component called Util is more accessible to you.

The following figure can be used to show the relationship between them:

Figure 2. Three component relationships

Detailed explanation of core components

The hierarchical relationships of the classes within each component and their timing order at run time are described in detail here. We should pay attention to the use of Spring.

Bean component

The Bean component is under the org.springframework.beans package of Spring. The only concern for Spring users is the creation of Bean. The other two are done internally by Spring and are transparent to you.

Spring Bean was created in a typical factory mode, and its top-level interface is BeanFactory.

BeanFactory has three subclasses: ListableBeanFactory, HierarchicalBeanFactory, and AutowireCapableBeanFactory. So why define so many levels of interfaces? Looking up the source code and description of these interfaces, it is found that each interface has its own occasion, which is mainly to distinguish the restrictions on the data access of objects during the transfer and transformation of objects in Spring. For example, the ListableBeanFactory interface indicates that these Bean are listable, while HierarchicalBeanFactory indicates that these Bean are inheritable, that is, each Bean may have a parent Bean. The AutowireCapableBeanFactory interface defines the automatic assembly rules for Bean.

The definition of Bean is mainly described by BeanDefinition

All future operations are done on this object.

The parsing process of Bean is very complex, and the functions are divided in detail, because there are so many areas that need to be extended, and there must be enough flexibility to cope with possible changes. The parsing of Bean is mainly the parsing of Spring configuration files.

Context component

Context is under the org.springframework.context package of Spring, which has previously explained the role of Context components in Spring. He is actually providing Spring with a runtime environment to save the state of each object. Let's take a look at how this environment is built.

ApplicationContext is the top-level parent of Context. In addition to identifying the basic information of an application environment, he also inherits five interfaces, which mainly extend the functions of Context. The following is the class structure diagram of Context:

Figure 7. Context-related class structure diagram

(see a clear version of figure 7. )

You can see from the above figure that ApplicationContext inherits BeanFactory, which also shows that the principal object running in the Spring container is Bean, and ApplicationContext inherits the ResourceLoader interface, so that ApplicationContext can access any external resources, which will be described in detail in Core.

The subclass of ApplicationContext mainly consists of two aspects:

1. ConfigurableApplicationContext indicates that the Context is modifiable, that is, in building a Context, users can dynamically add or modify existing configuration information, and there are several subclasses under it, of which the most frequently used is the updatable Context, that is, the AbstractRefreshableApplicationContext class.

2. WebApplicationContext, as the name implies, is the Context prepared for web. He can access ServletContext directly. Usually, this API is rarely used.

This level constitutes a complete Context hierarchy.

Overall, ApplicationContext must accomplish the following things:

Identify an application environment

Using BeanFactory to create Bean object

Save object relation table

Ability to capture all kinds of events

As the Ioc container of Spring, Context basically integrates most of the functions of Spring, or the basis of most functions.

Core component

As the core component of Spring, Core component contains many key classes, one of which is to define how to access resources. This way of abstracting all resources into a single interface is worth learning in future designs. Let's take an important look at the role of this section in Spring.

From the figure above, you can see that the Resource interface encapsulates a variety of possible resource types, that is, shielding the differences in file types for the user. It is also a problem for the resource provider to wrap the resource for others to use. We see that the Resource interface inherits the InputStreamSource interface, which has a getInputStream method that returns the InputStream class. In this way, all resources are available through the InputStream class, so the provider of the resource is also shielded. Another problem is the problem of loading resources, that is, the loaders of resources should be unified. You can see from the above figure that this task is completed by the ResourceLoader interface, which shields the differences of all resource loaders. You only need to implement this interface to load all resources. His default implementation is DefaultResourceLoader.

Let's take a look at how Context and Resource build a relationship.

Context entrusts the loading, parsing and description of resources to the ResourcePatternResolver class, which is equivalent to a connector. He integrates the loading, parsing and definition of resources to facilitate the use of other components. There are many similar ways in Core components.

How Ioc containers work

We have previously introduced the structure and interrelationship of Core components, Bean components and Context components. Let's take a look at how they run from the user's point of view, and how we let Spring complete various functions. What functions can Spring have? how did these functions come from?

How to create a BeanFactory factory

As depicted in figure 2, the Ioc container is actually a Context component that combines the other two components to build a Bean relationship network. How to build this relationship network? The entry for the build is in the refresh method of the AbstractApplicationContext class. The code for this method is as follows:

Listing 1. AbstractApplicationContext.refresh

one

two

three

four

five

six

seven

eight

nine

ten

eleven

twelve

thirteen

fourteen

fifteen

sixteen

seventeen

eighteen

nineteen

twenty

twenty-one

twenty-two

twenty-three

twenty-four

twenty-five

twenty-six

twenty-seven

twenty-eight

twenty-nine

thirty

thirty-one

thirty-two

thirty-three

thirty-four

thirty-five

thirty-six

thirty-seven

thirty-eight

Public void refresh () throws BeansException, IllegalStateException {

Synchronized (this.startupShutdownMonitor) {

/ / Prepare this context for refreshing.

PrepareRefresh ()

/ / Tell the subclass to refresh the internal bean factory.

ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory ()

/ / Prepare the bean factory for use in this context.

PrepareBeanFactory (beanFactory)

Try {

/ / Allows post-processing of the bean factory in context subclasses.

PostProcessBeanFactory (beanFactory)

/ / Invoke factory processors registered as beans in the context.

InvokeBeanFactoryPostProcessors (beanFactory)

/ / Register bean processors that intercept bean creation.

RegisterBeanPostProcessors (beanFactory)

/ / Initialize message source for this context.

InitMessageSource ()

/ / Initialize event multicaster for this context.

InitApplicationEventMulticaster ()

/ / Initialize other special beans in specific context subclasses.

OnRefresh ()

/ / Check for listener beans and register them.

RegisterListeners ()

/ / Instantiate all remaining (non-lazy-init) singletons.

FinishBeanFactoryInitialization (beanFactory)

/ / Last step: publish corresponding event.

FinishRefresh ()

}

Catch (BeansException ex) {

/ / Destroy already created singletons to avoid dangling resources.

DestroyBeans ()

/ / Reset 'active' flag.

CancelRefresh (ex)

/ / Propagate exception to caller.

Throw ex

}

}

}

This approach is to build the complete code of the entire Ioc container process, and knowing each line of code in it basically understands most of the principles and functions of Spring.

This code mainly consists of several steps:

Build BeanFactory to produce the required "actors"

Register events of possible interest

Create a Bean instance object

Trigger a monitored event

The following is a combination of code analysis of these processes.

The second three sentences are about creating and configuring BeanFactory. Here is refresh, that is, refresh configuration. It was introduced earlier that Context has updatable subclasses. This function is implemented here, which is updated when the BeanFactory already exists, or newly created if it does not exist. Here is the method code for updating BeanFactory:

Listing 2. AbstractRefreshableApplicationContext. RefreshBeanFactory

one

two

three

four

five

six

seven

eight

nine

ten

eleven

twelve

thirteen

fourteen

fifteen

sixteen

seventeen

eighteen

nineteen

twenty

Protected final void refreshBeanFactory () throws BeansException {

If (hasBeanFactory ()) {

DestroyBeans ()

CloseBeanFactory ()

}

Try {

DefaultListableBeanFactory beanFactory = createBeanFactory ()

BeanFactory.setSerializationId (getId ())

CustomizeBeanFactory (beanFactory)

LoadBeanDefinitions (beanFactory)

Synchronized (this.beanFactoryMonitor) {

This.beanFactory = beanFactory

}

}

Catch (IOException ex) {

Throw new ApplicationContextException (

"I take O error parsing bean definition source for"

+ getDisplayName (), ex)

}

}

This method implements the abstract method refreshBeanFactory of AbstractApplicationContext, and this code clearly illustrates the process of creating BeanFactory. Notice the change in the type of the BeanFactory object. It was described earlier that he has many subclasses, and it is critical to use different subclasses in which case. The original object of BeanFactory is DefaultListableBeanFactory, which is critical because it is designed to perform multiple operations on this object later.

From this diagram, we find that in addition to the classes related to BeanFactory, we also find that they are related to the register of Bean. There is a line of loadBeanDefinitions (beanFactory) in the refreshBeanFactory method that will find the answer, which will start loading and parsing the definition of Bean, that is, transforming the user-defined data structure into a specific data structure in the Ioc container.

This process can be explained by Bean's parsing and registration process sequence diagram.

After creating the BeanFactory, add some utility classes needed by the Spring itself, which is done in the prepareBeanFactory method of the AbstractApplicationContext.

The next three lines of code in AbstractApplicationContext play a vital role in the functional extensibility of Spring. The first two lines mainly allow you to make changes to the configuration of the BeanFactory you have built, and the second line allows you to add some custom actions when you create an instance object of Bean later. So they all extend the function of Spring, so we must understand this part if we want to learn to use Spring.

The main purpose of the invokeBeanFactoryPostProcessors method is to get the subclasses that implement the BeanFactoryPostProcessor interface. And execute its postProcessBeanFactory method, which is declared as follows:

Listing 3. BeanFactoryPostProcessor.postProcessBeanFactory

one

two

Void postProcessBeanFactory (ConfigurableListableBeanFactory beanFactory)

Throws BeansException

Its parameter is beanFactory, which means that beanFactory can be modified. Note here that the beanFactory is of ConfigurableListableBeanFactory type, which also confirms that different BeanFactory are used in different situations. Here, it can only be a configurable BeanFactory to prevent some data from being modified by users.

The registerBeanPostProcessors method can also take user-defined subclasses that implement the BeanPostProcessor interface and perform registering them in the beanPostProcessors variable in the BeanFactory object. Two methods are declared in BeanPostProcessor: postProcessBeforeInitialization and postProcessAfterInitialization are used to execute when the Bean object is initialized, respectively. You can perform user-defined actions.

The next few lines of code initialize listening events and register other listeners of the system, who must be subclasses of ApplicationListener.

How to create a Bean instance and build a Bean relationship network

Here is the instantiation code for Bean, starting with the finishBeanFactoryInitialization method.

Listing 4. AbstractApplicationContext.finishBeanFactoryInitialization

one

two

three

four

five

six

seven

eight

nine

ten

eleven

twelve

Protected void finishBeanFactoryInitialization (

ConfigurableListableBeanFactory beanFactory) {

/ / Stop using the temporary ClassLoader for type matching.

BeanFactory.setTempClassLoader (null)

/ / Allow for caching all bean definition metadata, not expecting further changes.

BeanFactory.freezeConfiguration ()

/ / Instantiate all remaining (non-lazy-init) singletons.

BeanFactory.preInstantiateSingletons ()

}

From the above code, you can see that the instantiation of Bean occurs in BeanFactory. The code for the preInstantiateSingletons method is as follows:

Listing 5. DefaultListableBeanFactory.preInstantiateSingletons

one

two

three

four

five

six

seven

eight

nine

ten

eleven

twelve

thirteen

fourteen

fifteen

sixteen

seventeen

eighteen

nineteen

twenty

twenty-one

twenty-two

twenty-three

twenty-four

twenty-five

twenty-six

twenty-seven

twenty-eight

twenty-nine

thirty

thirty-one

thirty-two

thirty-three

thirty-four

thirty-five

thirty-six

thirty-seven

Public void preInstantiateSingletons () throws BeansException {

If (this.logger.isInfoEnabled ()) {

This.logger.info ("Pre-instantiating singletons in" + this)

}

Synchronized (this.beanDefinitionMap) {

For (String beanName: this.beanDefinitionNames) {

RootBeanDefinition bd = getMergedLocalBeanDefinition (beanName)

If (! bd.isAbstract () & & bd.isSingleton ()

& &! bd.isLazyInit () {

If (isFactoryBean (beanName)) {

Final FactoryBean factory =

(FactoryBean) getBean (FACTORY_BEAN_PREFIX+ beanName)

Boolean isEagerInit

If (System.getSecurityManager ()! = null

& & factory instanceof SmartFactoryBean) {

IsEagerInit = AccessController.doPrivileged (

New PrivilegedAction () {

Public Boolean run () {

Return (SmartFactoryBean) factory. IsEagerInit ()

}

}, getAccessControlContext ()

}

Else {

IsEagerInit = factory instanceof SmartFactoryBean

& ((SmartFactoryBean) factory) .isEagerInit ()

}

If (isEagerInit) {

GetBean (beanName)

}

}

Else {

GetBean (beanName)

}

}

}

}

}

There is a very important Bean-FactoryBean. It can be said that more than half of the extended functions of Spring are related to this Bean. This is a special Bean, which is a factory Bean, which can generate Bean of Bean. Here, generating Bean refers to an instance of Bean. If a class inherits FactoryBean, users can define their own methods to generate instance objects as long as they implement his getObject method. However, in Spring, the instance object of this Bean is FactoryBean, and the user-defined object can be obtained by calling the getObject method of this object, which provides a good expansibility for Spring. Spring acquires the object of FactoryBean itself by adding & in front of it.

How to create instance objects of Bean and how to build relational Spring between Bean instance objects is a core key.

If it is a normal Bean, create its instance directly, by calling the getBean method.

Another very important part is to establish the relationship between Bean object instances, which is the core competitiveness of the Spring framework.

Extension points for Ioc containers

Now there is another problem is how to make these Bean objects extensible, that is, they can add some operations to users. So what are the extension points? How does Spring call to these extension points?

For Spring's Ioc containers, there are mainly a few. BeanFactoryPostProcessor, BeanPostProcessor . They are called when building a BeanFactory and a Bean object, respectively. Then there are InitializingBean and DisposableBean, which are called when the Bean instance is created and destroyed, respectively. Users can implement the methods defined in these interfaces, and Spring will call them at the appropriate time. Another is FactoryBean, which is a special Bean, and this Bean can be more controlled by users.

These extension points are usually also where we use Spring to accomplish our specific tasks. How to master Spring depends on whether you have a good grasp of Spring extension points and how to use them. To know how to use them, you must understand their internal mechanism. It can be explained by the following metaphor.

We compare the Ioc container to a box with several ball molds that can be used to make many different kinds of balls, and a machine that makes these ball molds. So their corresponding relationship is that BeanFactory is the machine that makes the ball model, the ball mold is Bean, and the ball created by the ball mold is an example of Bean. So where are the extension points mentioned above? BeanFactoryPostProcessor corresponds to when the ball-making model is created, you will have the opportunity to make appropriate modifications to it, that is, he can help you modify the ball model. While InitializingBean and DisposableBean are at the beginning and end of ball making, you can do some preparatory and finishing work. BeanPostProcessor allows you to make appropriate corrections to the ball created by the ball mold. Finally, there is a FactoryBean, which is a magical ball model. The ball model is not shaped in advance, but it is up to you to determine its shape. Since you can determine the shape of the ball model, of course, the ball he makes must be the ball you want, so that Ni can find all the balls you want in this box.

How the Ioc container works for me

When we use Spring, we must first build an Ioc container. Spring cannot work without it. ApplicatonContext.xml is the default configuration file of the Ioc container. All the features and functions of Spring are based on this Ioc container, such as AOP.

Ioc actually builds a Rubik's cube for you, and Spring builds a skeleton structure for you. What good things can this Rubik's cube come out? it requires your participation. So how do we get involved? As for how to implement extension points to get the personalized results we want, there are many examples in Spring, in which the implementation of AOP is that Spring itself implements its extension points to achieve the features it wants.

The AOP feature in Spring explains the implementation principle of dynamic agent in detail.

To understand the AOP of Spring, you must first understand the principle of dynamic proxy, because AOP is implemented on the basis of dynamic proxy. Dynamic agents also start with JDK itself.

Under the java.lang.reflect package of Jdk, there is a Proxy class, which is the entry point for constructing proxy classes.

It is found that the last four are public methods. The last method, newProxyInstance, is the method that creates the proxy object. The source code for this method is as follows:

Listing 6. Proxy. NewProxyInstance

one

two

three

four

five

six

seven

eight

nine

ten

eleven

twelve

thirteen

fourteen

fifteen

sixteen

seventeen

eighteen

nineteen

twenty

twenty-one

twenty-two

Public static Object newProxyInstance (ClassLoader loader

Class [] interfaces

InvocationHandler h)

Throws IllegalArgumentException {

If (h = = null) {

Throw new NullPointerException ()

}

Class cl = getProxyClass (loader, interfaces)

Try {

Constructor cons = cl.getConstructor (constructorParams)

Return (Object) cons.newInstance (new Object [] {h})

} catch (NoSuchMethodException e) {

Throw new InternalError (e.toString ())

} catch (IllegalAccessException e) {

Throw new InternalError (e.toString ())

} catch (InstantiationException e) {

Throw new InternalError (e.toString ())

} catch (InvocationTargetException e) {

Throw new InternalError (e.toString ())

}

}

This method requires three parameters: ClassLoader, which is used to load the Loader class of the proxy class, which is usually the same Loader class as the Loader. Interfaces are the interfaces that will be proxied. InvocationHandler, which is used to perform user-defined operations other than the methods in the proxied interface, is also the ultimate goal for users to need agents. The user calling the target method is proxied to the only method invoke defined in the InvocationHandler class. This will be explained in detail later.

Let's take a look at the process of how Proxy generates a proxy class, and what does the proxy class he constructs look like?

In fact, from the figure above, you can see that what is constructing the proxy class is in the generateProxyClass method of ProxyGenerator. The ProxyGenerator class is under the sun.misc package. If you are interested, you can take a look at his source code.

If there is such an interface, it is as follows:

Listing 7. SimpleProxy class

one

two

three

four

five

six

seven

Public interface SimpleProxy {

Public void simpleMethod1 ()

Public void simpleMethod2 ()

}

The class structure generated by the proxy is as follows:

Listing 8. $Proxy2 class

one

two

three

four

five

six

seven

eight

nine

ten

eleven

twelve

thirteen

Public class $Proxy2 extends java.lang.reflect.Proxy implements SimpleProxy {

Java.lang.reflect.Method m0

Java.lang.reflect.Method m1

Java.lang.reflect.Method m2

Java.lang.reflect.Method m3

Java.lang.reflect.Method m4

Int hashCode ()

Boolean equals (java.lang.Object)

Java.lang.String toString ()

Void simpleMethod1 ()

Void simpleMethod2 ()

}

The methods in this class will call the invoke method of InvocationHandler, and each method will correspond to a property variable, which will also be passed to the Method parameter in the invoke method. This is how the whole agent is implemented.

How to implement Spring AOP

We know from the principle of the proxy that the purpose of the proxy is that when we call the target method, we can instead execute the invoke method of the InvocationHandler class, so how to write an article on InvocationHandler is the key for Spring to achieve Aop.

The Aop implementation of Spring follows the agreement of the Aop alliance. At the same time, Spring extends it, adding some interfaces such as Pointcut, Advisor and so on to make it more flexible.

The figure above clearly shows that Spring references the interface defined by Aop Alliance. Without discussing how Spring extends Aop Alliance, let's take a look at how Spring implements the proxy class. To implement the proxy class, a Bean is usually specified in the Spring configuration file, as follows:

Listing 9. Configure the proxy class Bean

one

two

three

four

five

six

seven

eight

nine

ten

eleven

twelve

thirteen

fourteen

fifteen

sixteen

Org.springframework.aop.framework.PrototypeTargetTests$TestBean

True

TestInterceptor

TestInterceptor2

In the configuration, you can see that the interface to be proxied, the implementation class of the interface, that is, the target class, and the interceptor are called just before the target method is executed. Here, you can choose to use the various interceptors defined in Spring.

Let's take a look at how Spring completes the proxy and invokes the interceptor.

As mentioned earlier, Spring Aop also implements its own extension point to accomplish this feature, and from this proxy class, you can see that ProxyFactoryBean,FactoryBean, which inherits FactoryBean, is special in that it allows you to customize the object creation method. Of course, the proxy object is generated dynamically through the Proxy class.

After Spring creates a proxy object, when you call a method on the target object, it will be proxied to the invoke method of the InvocationHandler class, which has been explained earlier. Here the JdkDynamicAopProxy class implements the InvocationHandler interface.

Let's take a look at how Spring calls the interceptor.

All of the above are Jdk dynamic agents, and Spring also supports a CGLIB class proxy. If you are interested, see for yourself.

Analysis of Design patterns in Spring

There are also many design patterns used in Spring, such as factory pattern, singleton pattern, template pattern and so on.

Agent mode

Principle of agent mode

The proxy pattern is to create a proxy object for an object, and the proxy object controls the reference to the original object, and the creation of the proxy object can add some additional operations when calling the original object.

ProxySubject: in addition to implementing the interface defined by the abstract topic, the proxy class must also hold a reference to the proxy object

RealSubject: the class being delegated, which is the target object.

How to implement Agent pattern in Spring

Jdk dynamic agent in Spring Aop is realized by using agent mode technology. In Spring, in addition to implementing the interface of the proxied object, there will be two interfaces, org.springframework.aop.SpringProxy and org.springframework.aop.framework.Advised.

Proxy is the proxy object created, while Subject is the abstract theme, and the proxy object holds a reference to the target object through InvocationHandler.

A real proxy object in Spring is structured as follows:

Listing 10 proxy object $Proxy4

one

two

three

four

five

six

seven

eight

nine

ten

eleven

twelve

thirteen

fourteen

fifteen

sixteen

seventeen

eighteen

nineteen

twenty

twenty-one

twenty-two

twenty-three

twenty-four

twenty-five

twenty-six

twenty-seven

twenty-eight

twenty-nine

thirty

thirty-one

thirty-two

thirty-three

thirty-four

thirty-five

thirty-six

thirty-seven

thirty-eight

thirty-nine

forty

forty-one

forty-two

forty-three

forty-four

forty-five

forty-six

forty-seven

forty-eight

forty-nine

fifty

fifty-one

fifty-two

fifty-three

fifty-four

fifty-five

fifty-six

fifty-seven

fifty-eight

fifty-nine

sixty

sixty-one

sixty-two

sixty-three

sixty-four

sixty-five

sixty-six

sixty-seven

sixty-eight

sixty-nine

seventy

seventy-one

Public class $Proxy4 extends java.lang.reflect.Proxy implements

Org.springframework.aop.framework.PrototypeTargetTests$TestBean

Org.springframework.aop.SpringProxy

Org.springframework.aop.framework.Advised

{

Java.lang.reflect.Method m16

Java.lang.reflect.Method m9

Java.lang.reflect.Method m25

Java.lang.reflect.Method m5

Java.lang.reflect.Method m2

Java.lang.reflect.Method m23

Java.lang.reflect.Method m18

Java.lang.reflect.Method m26

Java.lang.reflect.Method m6

Java.lang.reflect.Method m28

Java.lang.reflect.Method m14

Java.lang.reflect.Method m12

Java.lang.reflect.Method m27

Java.lang.reflect.Method m11

Java.lang.reflect.Method m22

Java.lang.reflect.Method m3

Java.lang.reflect.Method m8

Java.lang.reflect.Method m4

Java.lang.reflect.Method m19

Java.lang.reflect.Method m7

Java.lang.reflect.Method m15

Java.lang.reflect.Method m20

Java.lang.reflect.Method m10

Java.lang.reflect.Method m1

Java.lang.reflect.Method m17

Java.lang.reflect.Method m21

Java.lang.reflect.Method m0

Java.lang.reflect.Method m13

Java.lang.reflect.Method m24

Int hashCode ()

Int indexOf (org.springframework.aop.Advisor)

Int indexOf (org.aopalliance.aop.Advice)

Boolean equals (java.lang.Object)

Java.lang.String toString ()

Void sayhello ()

Void doSomething ()

Void doSomething2 ()

Java.lang.Class getProxiedInterfaces ()

Java.lang.Class getTargetClass ()

Boolean isProxyTargetClass ()

Org.springframework.aop.Advisor; getAdvisors ()

Void addAdvisor (int, org.springframework.aop.Advisor)

Throws org.springframework.aop.framework.AopConfigException

Void addAdvisor (org.springframework.aop.Advisor)

Throws org.springframework.aop.framework.AopConfigException

Void setTargetSource (org.springframework.aop.TargetSource)

Org.springframework.aop.TargetSource getTargetSource ()

Void setPreFiltered (boolean)

Boolean isPreFiltered ()

Boolean isInterfaceProxied (java.lang.Class)

Boolean removeAdvisor (org.springframework.aop.Advisor)

Void removeAdvisor (int) throws org.springframework.aop.framework.AopConfigException

Boolean replaceAdvisor (org.springframework.aop.Advisor

Org.springframework.aop.Advisor)

Throws org.springframework.aop.framework.AopConfigException

Void addAdvice (org.aopalliance.aop.Advice)

Throws org.springframework.aop.framework.AopConfigException

Void addAdvice (int, org.aopalliance.aop.Advice)

Throws org.springframework.aop.framework.AopConfigException

Boolean removeAdvice (org.aopalliance.aop.Advice)

Java.lang.String toProxyConfigString ()

Boolean isFrozen ()

Void setExposeProxy (boolean)

Boolean isExposeProxy ()

}

Strategy mode

Principle of strategic mode

As the name implies, the strategy pattern is the strategy to do something, which usually means that there are many ways to accomplish an operation, each of which has its own advantages and different adaptations, but all of which may be used. Each operation method is treated as an implementation strategy, and the user may choose the appropriate strategy according to the need.

Context: using an environment with different policies, it can choose different policy implementation classes according to its own conditions to complete the desired operation. It holds a reference to a policy instance. The method of creating a specific policy object can also be done by him.

Strategy: abstract policies, defining policy methods to be implemented for each policy

ConcreteStrategy: concrete policy implementation class that implements policy methods defined in abstract policies

Implementation of Policy pattern in Spring

The policy pattern in Spring is used in many places, such as the creation of Bean definition objects and proxy objects. Here we mainly look at the implementation of the policy pattern created by the proxy object.

You have already seen that there are two Jdk dynamic proxies and CGLIB proxies for Spring. The use of these two agents uses the policy mode.

The above structure diagram is slightly different from the standard policy pattern structure, where the abstract policy is the AopProxy interface, Cglib2AopProxy and JdkDynamicAopProxy represent the implementation of the two policies respectively, and ProxyFactoryBean represents the Context role, which chooses to use Jdk proxy or CGLIB according to the conditions, while the other three classes are mainly responsible for creating specific policy objects. ProxyFactoryBean is related to specific policy objects through dependent methods. It does this by calling the getProxy (ClassLoader classLoader) method of the policy object.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

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.