NET design Pattern Part II Structural model (14): Thematic summary of structural patterns

Source: Internet
Author: User

--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

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.