--Explore the design pattern series
TERRYLEE,2006 year May
Abstract: The structural pattern, as the name implies, discusses the structure of classes and objects, which use inheritance to combine interfaces or implementations (class-structured patterns), or to implement new functions (object-structured patterns) by combining some objects. These structural patterns, which have a great similarity in some respects, are carefully scrutinized and have different emphases. This paper attempts to make a brief summary of these types of structural patterns.
Main content
1. Overview of structural patterns
2. Differences and comparisons of structural patterns
3. The package for the change
Overview of structural patterns
The structural pattern, as the name implies, discusses the structure of classes and objects, which use inheritance to combine interfaces or implementations (class-structured patterns), or to combine objects to implement new functionality (object-structured patterns). These structural patterns, which have a great similarity in some respects, are carefully scrutinized and have different emphases.
The adapter pattern is focused on transforming existing interfaces through the inheritance of classes or the combination of objects, and bridge mode, by separating the abstractions from the implementations, allows them to change independently of each other, emphasizing the changes in the system along multiple directions, and the decorator pattern using object combinations rather than inheritance. The ability to dynamically extend the object function at run time, which emphasizes the extension interface, composite mode blurs the concept of simple elements and complex elements, it emphasizes a kind of hierarchical structure, and the Façade mode decouples the internal subsystem of complex system from the dependence of the client program. It focuses on simplifying the interface, more of an architectural pattern, and the flyweight pattern solves the problem of memory overhead caused by a large number of fine-grained objects, which is the opposite of the façade pattern, with a focus on small objects The proxy mode provides a proxy for other objects to control access to the object, and it focuses on adding the indirection layer to simplify complex problems.
Differences and comparisons of structural patterns
1. Bridging mode and decorative mode
These two patterns are to some extent to reduce the number of subclasses and avoid complex inheritance relationships. However, the methods they solve are different, the decorative mode of the class in the more than the base class in a separate class, to adapt to the need for new functions, when we describe the new function of the class encapsulated in the base class object, we get the necessary subclass object, The classes that describe the new functionality can be combined to achieve a number of functional combinations, and the thumbnail of the decorating pattern is as follows:
Figure 1 Decorative pattern thumbnail
Bridge mode is the original base class implementation of the details of the abstraction, in the construction of an implementation of the structure, and then the original base class into an abstract hierarchical structure, so that the system can achieve independent changes in multiple dimensions, bridging the pattern of the following diagram:
Figure 2 Bridging mode thumbnail
2. Appearance mode and proxy mode
The appearance mode and the agent pattern solves the problem the focus is different, but they solve the problem the method is the same, namely all has introduced the indirect layer the technique, this is also our software system frequently uses the method. Although the appearance mode is focused on simplifying the interface, in some cases, the appearance mode can also be the responsibility of the proxy mode, such as the appearance object may be another remote agent located in another address space object, we can call the Appearance proxy mode, or proxy appearance mode. Their class sketch is as follows:
Figure 3 Proxy mode thumbnail
Figure 4 Appearance pattern thumbnail
3. Adapter mode
Adapter mode is heavy in the conversion interface, it can not work together in the original two classes work together, so often used in the class library reuse, code migration, and so on, there is a taste of the mend. class adapters and object adapters can be selected according to the actual situation, but it is generally recommended that you use the object adapter pattern, as shown in the class adapter mode on the left and the object adapter mode on the right:
Figure 5 Adapter Mode thumbnail
The package for the change
How to deal with change, is a perpetual theme of software development, perhaps we can not prevent the occurrence of change, but at least we have some means to minimize change. "Finding a system variable, encapsulating it," is often called a package of changes. The explanation of this problem is clear in Java and schema, the simple implementation of abstraction and implementation, the simplest implementation of the "open-close" principle at the class level, as shown in:
Figure 6
In this inheritance structure, the first layer is abstract, it encapsulates the abstract business logic, which is the invariant part of the system, the second layer is implementation, it is the implementation of the specific business logic, encapsulates the changes in the system, this implementation allows the implementation of the changes in the role polymorphism:
Figure 7
In other words, the client relies on an abstract type of object for the business logic, regardless of the abstraction of the concrete implementation, whether it is "implementation", "Implementation 2" or "Implementation 3" as shown in:
Figure 8
Each inheritance relationship encapsulates a change factor, and an inheritance relationship should not deal with two variables, in other words, this simple inheritance relationship cannot handle both abstraction and implementation changes, as shown in:
Figure 9
The two factors in the change should be independent, can be independent change without affecting the other accesses than either, such as the following two hierarchy structure of their own change, as each change factor can be expressed through static relationship, so the use of inheritance relationship, such as:
Figure 10
What about the connection between abstraction and implementation? Good design has only one, bad design but there are many, the following design is to continue to use inheritance for static relationship design of the class diagram:
Figure 11
In fact, there are many problems in this kind of design, first of all, there are multiple inheritance relationships, and as the concrete implementation increases, the inheritance of subclasses becomes very complicated, and secondly, if there are new abstractions or new concrete implementation roles, we have to re-modify the static relationship in the existing system to adapt to the new role. This violates the open-closed principle. The correct design should be to use two separate hierarchical structures to encapsulate two independent variables and use aggregation between them to achieve the purpose of functional multiplexing, which goes back to our bridging mode, as shown in:
Figure 12
From another perspective, a good design usually does not have more than two levels of inheritance hierarchy, or, if there are more than two variables, you need to find out which factor is static, you can use static relationships, which is dynamic, you must use the aggregation relationship.
More design Patterns articles can be accessed in the. NET Design Patterns series articles "
Resources
Erich Gamma, etc., "design mode: The basis of reusable object-oriented software", Mechanical industry Press
Robert C.martin, "Agile Software Development: principles, patterns and practices", Tsinghua University Press
Shanhong, Java and patterns, electronic industry publishing house
Alan Shalloway James R. Trott, "Design Patterns explained", China Power Press
NET design Pattern Part II Structural model (14): Thematic summary of structural patterns