A summary of the interface pattern of Java design patterns

Abstract: Original works, can be reproduced, but please mark the source address: http://www.cnblogs.com/V1haoge/p/6508967.html

Previously, we studied the four interface modes in Java design mode: Adapter mode (Adapter), appearance mode (facade), synthetic mode (Composite), Bridging mode (bridge).

1. Review the four design patterns in this place:

(1) Adapter mode:

We can access the class does not exist in the content that we want to access, it is possible to use this adapter mode, of course, in terms of the class, there is no access to what is not, here is not access to human constraints, rules of the restrictions.

The most common is the MVC layering pattern used in regular projects, especially in SPRINGMVC: Our request came to Springmvc's core servlet (Dispatcherservlet) for a request to be distributed, To find the appropriate controller, the general controller will not do any business processing, its role is to receive requests and return responses, and the specific request and response processing is at the business Layer (service layer) implementation.

The purpose of this request is clear, that is, to do business processing, and the controller receiving the request is not allowed to have any business code inside, what to do? This is a typical application of the adapter pattern by treating it as an adapter, using a combination of methods to refer to the business class in the class where the controller is located (the interface points to the implementation class), and then invoking the method in the Controller method that can accomplish the purpose of the request in one or several business layer classes.

Please refer to "adapter mode" and "Application Scenario" in Java design mode

(2) Appearance mode:

Appearance is face, backyards, not to say that we must use the appearance, but the use of the appearance can have many advantages, it is able to mask the complexity of the system, and if the implementation of the system function is optimized or changed, only need to make a simple update of the appearance class, without affecting the use of the system of other systems, This is the most important feature of the appearance class.

Here I suddenly thought, the above example, the controller calls the business Layer implementation class to complete the specific business processing, from a certain point of view, is also an application of the appearance pattern: The Controller class for the entire Web site business system is not an appearance class exists, external requests came to the system backstage, This is the controller class, not the complex business processing class, in the controller by invoking the business class method to provide services for external requests, so that the entire complex backend business system is interface masking, the requester does not have to care about which business class to invoke to implement their own requests, Instead, there is a specific controller to complete this internal call. When we modify or update the business implementation method, we only need to make a slight change in the controller, the whole request has no effect, and nothing has changed.

Just suddenly think of a point: I remember that in the appearance of the description of the model, the appearance of the system is not a real shield, other systems can be directly called the system through the internal methods to complete the function, but it is more complex, which in the SPRINGMVC seems to be impossible to achieve, Because SPRINGMVC is designed to be an interface matching method to find the controller, which means that the request comes only to the controller, it is not possible to invoke the business implementation class directly, perhaps through some complex way can be achieved.

Please refer to "appearance mode" and "Application Scenario" in Java design mode.

(3) Synthetic mode:

Different from the previous and later to talk about the model, I think the synthetic mode is more narrow, refers to the narrow application, as if the main target is the tree structure, such as file directory, multilevel directory structure.

The purpose of using the compositing pattern is not to combine (the next level is included in the upper level), but to treat it equally.

What is the same? Simply put, the tree structure of the two forms generalize, the directory structure of the file and directory generalize, rather than divided.

If the two are treated equally, then they can be abstracted into a concept (usually should be expressed in abstract class), and then we will separate the implementation of the abstract inheritance, the specific distinction between them, this is as if the structure is more complex than the original, but, in fact, we use the abstract, The two are summed up as a concept, so that when we use it, we can use the same interface to implement (polymorphic in Java: Abstract class to the implementation class), the implementation does not have to be specified in the code, but automatically according to the situation to complete. This simplifies the code by eliminating the need for explicit calls to separate them.

Please refer to "Bridging Mode" and "Application Scenario" in Java design mode

(4) Bridge mode:

Many previous articles have not been in the blog home page to retain, but this article "Java design mode" bridge mode "and application scenario" altogether into the editor's eye, and then Dahne Technology released to the "Headlines today", that this article is still good.

Said bridge mode, also known as bridge mode, words too literally, is a bridge. This is an interface bridge.

Read a lot of literature, said bridge mode is the abstraction and implementation decoupling, say the truth, do not understand! Because this sentence itself is extremely abstract, talk about how to understand!

In fact, the abstract here refers to the caller's abstract class implementation, the implementation refers to the interface implementation of the callee, here to talk about the two implementation, it is our common implementation: it is through the inheritance of the way to achieve the abstract class, through the implementation of the way to implement the interface, no matter what.

Again, decoupling, the decoupling is also very good understanding, is to remove the direct coupling, what style of direct coupling, very simple, through the way of inheriting the class is directly coupled, such a coupling leads to modification and expansion will be extremely troublesome, this is the purpose of decoupling.

And then how to decouple, the two parties involved here is the caller and the callee, if through the inheritance of the way to carry out the Java inheritance rules, but the coupling is too large, not easy to expand, so in between the two to set up a bridge between the kind of coupling separated, through the middle bridge to connect, so, The expansion of both sides no longer has any impact on each other, can be arbitrarily developed.

So how to build this bridge?

Very simply, using the two artifacts of interface and abstract class, we create an interface for the callee, and this interface is the bridge, in fact we bind the bridge with the callee, and for the caller, we create an abstract class (why is this an abstract class instead of an interface?). Because we are going to refer to the bridge interface inside this abstract class, and the interface is generally not a property of < only static constant >), use abstract class, in which the bridge interface is referenced, and create the appropriate method for the inherited class implementation to be extended.

In this way, the purpose of achieving, do not understand, please see the Java design mode of the "bridge mode" and the application scenario article.

2. Interface type

The above four design patterns are related to the interface, where the interface is not interface this meaning, but a "foreign" or "called" meaning, there is a layer of shielding meaning.

The interface type mostly uses the interface to block the specific implementation, providing the caller with a friendly interface (the contact port).

(Understanding is still shallow, to be added)

　　

"Combinatorial Mode" and application scenario of Java design pattern

A summary of the interface pattern of Java design patterns