Spring analysis of Design patterns MySQL Oracle HTML5

Spring analysis of design patterns

Spring has been in the Java world for years, but it's not easy to read. In particular, the extensive use of the interface concept, but also increased the difficulty of analysis, this article from the point of view of design patterns to analyze it, will ignore the implementation of the specific details. In this article, the model that spring involves is not from the official, perhaps some places will make the reader feel farfetched, purely personal opinion, hope readers criticize reading.

We will start by discussing the relationship between Beanfactory and ApplicationContext to open the gates of spring (in fact the relationship between Abstractapplicationcontext and Defaultlistablebeanfactory) 。 In short, the central role of Beanfactory is to create a bean,applicationcontext that creates beanfactory and provides us with a unified access interface. Let's take a look at their class diagram relationships.

The other auxiliary interfaces are omitted here, leaving only the relationship between them so that we can analyze them. We can describe the role of Abstractapplicationcontext: Abstractapplicationcontext actually acts as an intermediary between the client and the defaultlistablebeanfactory. , that is, we can not directly access beanfactory, but through ApplicationContext to access. This makes it clear that the intent of the proxy pattern is exactly the same. It is clear that the relationship between Beanfactory and ApplicationContext helps us to control the structure of the frame in general, so as not to confuse too many interfaces.

As mentioned above, an important role of ApplicationContext is to create beanfactory. The construction process of beanfactory is transparent to us, so is there any way we can expand Beanfactory's behavior? This is when the Beanfactorypostprocessor interface is involved. The function of this interface is to enrich and extend the beanfactory function.

According to this, is this a design pattern? Yes, I found a URL diagram of an observer pattern on the Web.

Can we describe what that means? Multiple beanfactorypostprocessor are also observing the construction of defaultlistablebeanfactory, and once the build is complete, it is sent to all observers to enrich its functionality. From this point of view this is the observer undoubtedly. Let's take a look at the structure of the responsibility chain model.

One of the main characteristics of the responsibility chain is that the sub-class forms a linked list structure. Since it is a linked list, we can make a little improvement by changing the list to an array. If all elements in the linked list are executed. Then the chain of responsibility model handy formed the following structure

From this point of view beanfactorypostprocessor structure, more like the responsibility chain model. So what kind of structure does he belong to? Analyzing from a class diagram, he prefers the observer pattern, but the intent is inconsistent, and the observer's intention is that when the event occurs, the subclass updates its behavior. For example, the Applicationlistener interface is described below, but the intent here is to enrich beanfactory behavior . if analyzed from the intention, more like the responsibility chain mode. Enrich the beanfactory behavior in a chain structure. It's just that the list structure is changed to an array structure. So here's the conclusion: I don't know. It could be the observer, perhaps the chain of responsibility, or the combination of the two, which is more likely to be nothing at all. The specific reader's own verdict. The Beanpostprocessor interface also enriches the process of modifying specific beans with the same structure.

Well, now the Bean Factory is building up. Before creating the Bean object defined in XML, the first thing beanfactory to do is to parse the tags in the XML into beandefinition that beanfactory can recognize.

The first question: How do we load our XML files in such a way? More specifically, our XML might be a local file, or it might be downloaded remotely, and it might already exist in binary memory. How do we abstract these possible situations? And then how to load into the program? Spring's approach is to unify these possible methods into the resource interface, which defines the Resourceloader interface specifically to load resource. Their relationship is as follows:

Did you see it? Yes, Spring uses the factory method design pattern to load the XML file into memory. When we started using spring in new classpathxmlapplicationcontext, we actually chose the mode of loading and chose the corresponding resource pattern.

The second problem is that the data is loaded into memory, and our next goal is to parse the XML file naturally. If you have a little bit of spring experience, you know that in addition to the <bean> tags in XML there are a variety of other tags, such as transactional, AOP, and so on, some readers may also want to customize to meet the tag. What about this? The problem always follows, let's take a look at spring's approach, such as

For different namespaces in XML, Spring uses the policy model to provide the perfect solution. If you are interested, you can draw a structure diagram of the Beandefinitionparse interface. You will find that he is still a strategic model. It is important to note that spring automatically scans the classpath meta-inf/spring.handlers configuration file for the relevant policy implementation class.

At this point, Spring can parse the XML file completely. The next step is to build our configured beans boldly. As mentioned above, if we want to enrich, expand, and change the bean build process. You can use the Beanpostprocessor interface. Typical AOP, proxies, and transactions are all extended through this interface. Our extension points are also here. Please refer to the BEANFACTORYPOSTPROCESSOR structure for his structure.

After the bean is created, spring is basically finished working on the big factory. At this point he will send an event informing the relevant interface. The structure diagram is as follows

Without any suspense, this is a typical application of the observer pattern.

There are also two design patterns, one is the template method. There is no doubt that this layered inheritance structure of spring is heavily used by template methods. The other is the façade mode,

ApplicationContext the integration of a large number of auxiliary interfaces, providing us with a unified façade.

The analysis ends here. Design patterns are an important tool for learning various frameworks. Identify is which design pattern generally requires two steps, the first look at the "face", that is, the class diagram structure is similar, the second look at the "heart", that is, the intention is consistent. Or that sentence, the main thing is not that we see what kind of design patterns, the most important is that we in the analysis of the thinking process, in the analysis of the design patterns of the specific use of the model and for the different problems of the abstract process.

Java enterprise-Class generic rights security framework source SPRINGMVC MyBatis or Hibernate+ehcache Shiro Druid Bootstrap HTML5

"Java Framework source code download"

Spring analysis of Design patterns MySQL Oracle HTML5