Design Model Structure
Design Model Structure
1 Structural Patterns
Description of how the succession and the combination of objects to solve common problems in application development.
1.1 The Adapter Patten
To a certain kind of interface has been converted into client are looking forward to another interface, so that does not match the original interface by not working together of the two categories can work together.
There are two ways to achieve:
1.1.1 The Object Adapter
Through a combination of achieving targets.
1.1.2 The Class Adapter
Through class inheritance to achieve.
1.2 The Composite Patten
Used to describe the practical application of the targets often encountered in the tree hierarchy. Basic class diagram:
Leaf (Leaf) and Branch (branch) have a common interface TreeNode so that the client can in a unified approach to visit each tree node.
Leaf could not be any other sub-node, we do not get support / add / remove son node operation. The Branch should get / add / remove son node operation.
As Leaf and Branch support of the operation not completely consistent, concrete realization can be in two ways:
Leaf through 1.2.1 and Branch distinguish between different interface
Given a TreeNode node, when necessary, through the "if (node instancof IBranch)" or "if (node instanceof ILeaf)" to judge it is the Leaf or Branch, thus gaining their support for the operation.
1.2.2 Leaf and Branch since achieving common interface
1.2.2.1 common interface, different realization
Leaf Branch and the realization of the common TreeNode interface, the interface definition tree node support for the operation of the Collection. Leaf for each operation does not support the realization of the given an empty (that is, after the completion of operation, without any impact Leaf nodes). For this to be the TreeNode node, client without distinction or Leaf Branch, as all can be operated on its role.
1.2.2.2 common interface, the same realization
In the common interface TreeNode increase in the "boolean isLeaf ()" method, is used to differentiate between nodes Leaf or Branch.
In the Java Swing JTree tree node is to take this design approach.
1.3 The Decorator Pattern
The basic functions needed to produce the permutations and combinations of the function of scenes, if we adopt inheritance, it will certainly
For every possible combination of a sub-class. The Decorator pattern can be elegant solution to the problem. Java I / O libraries on the design of large-scale application of the Decorator pattern.
Multiple users on-demand Decorator role in the permutations and combinations ConcreteComponent above, so as to the basic function () to add new features.
1.4 The Proxy Pattern
As the name suggests, a good understanding. By Proxy, direct control of the client to create and access core RealSubject.
Practical applications, often used in the model, Java 2 and java.lang.reflect.InvocationHandler java.lang.reflect.Proxy has provided a basic, enabling users to easily create dynamic of a class agent.
1.5 The Flyweight Pattern
Actually create single-instance mode of expansion. ShareObjectFactory responsible for the creation of a limited field and a ShareObject, these finite ShareObject be shared throughout the system. ShareObjectFactory its general design for the single-instance. As XXXShareObject examples to be shared throughout the system, it is generally designed to be lightweight (Flyweight) can not change the category, and the basis for the operation of the external variable state, as a general method of the parameters of the introduction.
1.6 The Façade Pattern
A complex system, it should be external to provide a unified, easy-to-use Façade (cosmetic) interface / category. Façade client through the interaction with the system, rather than directly with the system's internal components / communications category. In this way, easy to design loosely coupled stratification of the various subsystems; and when a subsystem changes, up to its Façade adjusted, the system does not affect other parts.
For example, Hibernate ORM as a realization in itself is a complex system. But through its external provide Configure / SessionFactory / Session / Query, and other interface or type, user friendly, and these interface or Hibernate category is the Façade.
1.7 The Bridge Pattern
Examples of the introduction 1.7.1
Personal view, Bridge Pattern structural model is the most difficult one to understand.
Good example is better than a thousand words. Assumptions to design a cross-platform browser, and display formats is the picture Liu
Browser an important function. Set up to support the current picture formats gif, bmp, jpg, png, pcx and tiff six, and the browser should support the operation of the Windows platform, and Unix Macinotosh three. A picture format of the internal data structures (ie picture binary file format) is clearly fixed, and that their platform will not show any relationship. And the right to set the picture, and how to load and display platform related to different platforms have different load and display.
Demand clear, how to design? An intuitive interface design is a definition of Image, and then a picture format for each platform and the combination provided a category, a total of 6 × 3 = 18. As shown below:
So designed to bring the question is:
1. Subclass excessive;
2. A large number of sub-categories may repeat code. For example, each GifInXXX class load () method have all *. gif file parsing code snippet, and the code is the same.
3. Picture format and the picture showed that in the code-level platform interdependence. GIF picture format assumption that changes in the structure of the internal data, a need to amend all GifInXXX; assumption on the Windows platform picture display expansion, the need to revise all XXXInWindows category.
Therefore, the need for further analysis, given the new design. Object-oriented analysis of an important means of "variable points and find the package (find what varies and encapsulate it)." Of this system, there are two variables:
Variable Point 1: picture loading / picture display format based on the variable;
Variable Point 2: picture loading / display browser based on variable operating platform.
And the two should be independent variable changes, no dependence. Variable points on 2 PlatformPresentHandler abstract interface to a different platform is different implementations. The picture of different formats have one pair of PlatformPresentHandler citations handlder, designated for dynamic picture display platform, while only package format associated with the respective load / display code. Complete picture loading / display format by the relevant code and related method combination handler completed. Finally, the picture of all the different formats for further AbstractImage abstract to the browser in a unified way to deal with different formats picture. As shown below:
This design, the benefits are plain to see:
L decrease in the number of sub-categories, only 6 +3 = 9;
L When a new picture format, simply add a XXXImage; some existing picture format changes, only a modification of a XXXImage counterparts;
L When a new platform support, simply add a XXXHandler; platform to the existing picture display some new requirements, only a modification of a XXXHandler corresponding category.
In fact, the application of such a design is the so-called Bridge Pattern. From Class Diagram view, AbstractImage / PlatformPresentHandler like AXXXImage series, and a bridge between the XXXHandler series.
1.7.2 refining
1. Basic Class Diagram
2. Apply occasions
Realization of a component dependent on a number of variables, which are not interdependent variable point, changes can be independent. Posted on 2007-04-21 13:54 RogerTu reading (622) Comments (0) edit their collections quoted Category: Programming Thought
Tags: the design pattern