Summary of structural design patterns (Part 1)

Adapter adapter:

"Some Existing objects" are applied in the new environment, but the interfaces required by the new environment are not met by these existing objects.

Converts an interface of a class to another interface that the customer wants. The adapter mode makes the class that cannot work together due to incompatibility of the interface.

To work together.

Object Adapter: Combination of objects, loose coupling
Class adapter: implements Multi-inheritance with fewer

The adapter mode is mainly used to reuse existing classes, but the interfaces are inconsistent with the requirements of the Reuse Environment.

And library migration.

The adapter mode itself requires us to use "interface-Oriented Programming" as much as possible so that we can easily adapt to it later.

Bridge:
For example, we need to develop a tank game that supports both PC and mobile phones. The game features the same on both PC and mobile phones, and has the same type and faces the same functional requirements, for example, a tank may have multiple models: t50, t75 ..... we may be able to easily design tanks.

Calculate the abstract base class of a tank, and then the different types of tank inherit from the class. However, image rendering, sound effects, and operations on PCs and mobile phones are completely different. Therefore, tanks of various types must be implemented on different platforms. This design will bring about many problems: There are many

Repeated code: the class structure is too complex and difficult to maintain. The most fatal thing is that introducing any new platform, such as TV, will complicate the entire class hierarchy.

.
The crux of the problem: in fact, the tank type has two changing dimensions:

"Platform changes" and "model changes ".
How to cope with "changes to dimensions ".

Bridge intent: Separate the abstract part from the implementation (or abstract) part so that they can be independent. --- Separation of "Changes in multiple dimensions"

.

Object combination. (This function can also be implemented through multi-inheritance, but it becomes "tightly coupled ")
Make the dimensions of "Platform" and "model" change independently, and then you can combine them to obtain different models on different platforms.

The bridge mode is generally used in "two very strong changing dimensions". Sometimes, even if there are two changing dimensions

Not drastic-in other words, the two changes do not result in vertical and horizontal disconnections, and do not necessarily use the bridge mode.

Composite combination:
A class of objects with the "Container" feature-that is, they are containers of other objects when acting as objects.

At this time, the customer must know the structure of the "container" and perform complex recursive operations.

The root cause of the problem described above is that the customer code is too dependent on the complex internal implementation structure of the object container, and the internal implementation structure of the object container (instead

Such as interface) changes will cause frequent changes in Customer Code, resulting in code maintainability, scalability and other drawbacks.

Purpose: Combine objects into a tree structure to represent the "part-whole" hierarchy. Composite enables users to enable a single object and a composite object

Use with consistency. (Complex structure operations are implemented within the object itself and only provide external customers with a simple interface)

Decorator Decoration:
Example: If we need to develop a tank for the game, in addition to the various types of tanks, we also want to add one for it on different occasions.

Or a variety of functions, such as infrared night vision, amphibious functions, satellite positioning, and so on.

General Practice:
// Abstract Tank
Public abstract class tank {}
// Various models
Public class T50: Tank {}
Public class T75: Tank {}
Public class t80: Tank {}
// Different function combinations
Public class t50a: t50, Ia {}
Public class t50b: t50, IB {}
Public class t75ab: T75, IA, IB {}
......
The above problem is that we "over-use inheritance to extend the object's functions", because inheritance is a type-introduced static feature, this extension method is missing

Lack of flexibility, and with the increase of sub-classes (adding a function, adding a sub-class), the combination of various functions will lead to the expansion of more sub-classes.

How can we enable "extension of object functions" to be dynamically implemented (runtime) as needed )? Avoid subclass expansion at the same time? So that any "Function

Is the impact of scaling changes minimized?

Decorator intent: dynamically add some additional responsibilities (functions) to an object ).

Public abstract tank {}
Public abstract T50: Tank {}
Public decorator: Tank {call the function of tank}

// It is not a link of is a, and is expressed as a composite link of has a in implementation.
// Function
Public decoratora: decorator {input the tank type in the constructor

}
Public decoratorb: decorator {input the tank type in the constructor

}
Public decoratorc: decorator {input the tank type in the constructor

}

Class app
{Tank tank50 = new T50 ();
Decoratora da = new decoratora (tank50 );
Decoratorc da = new decoratorc (tank50 );
Tank tank75 = new T75 ();
Decoratora da = new decoratora (tank75 );
Decoratorc da = new decoratorc (tank75); // you can

Arbitrary scaling.
}

The decorator mode does not solve the problem of "Multi-subclass-derived multi-inheritance", but is to solve the problem of "the extension function of the Subject Class in multiple directions"-This is

Is the meaning of decoration.

Facade appearance:
How to simplify the interaction interfaces between external client programs and systems? How to decouple the dependency between the evolution of external customer programs and the changes of internal subsystems

.
Facade intent: provide a consistent interface for a group of sub-system interfaces,

The facade mode defines a high-level interface, which makes this subsystem easier to use.

Key points:
1. It not only simplifies the interface of the entire component system, but also achieves a "decoupling" for the internal and external customer programs of the component"

Effect-any changes to the internal subsystem will not affect the changes to the facade interface.
2. The facade design model focuses more on the entire system from the architectural level, rather than the individual class level. In most cases, facade is an architectural design mode.
3. The facade mode focuses on simplified interfaces, the adapter mode focuses on conversion interfaces, the Bridge Mode focuses on Separated interfaces (abstraction) and implementation, and the decorator Mode

Object Extension function, with a focus on stable interfaces.

Flyweight ):
The problem with the use of pure object solutions is that a large number of fine-grained objects will soon flood the system, resulting in a high operating price-mainly pointing to the internal

Cost of demand side.
While avoiding a large number of fine-grained objects, how can external customer programs still operate transparently?

Flyweight intends to use the sharing technology to effectively support a large number of fine-grained objects.

The flyweight mode mainly solves the problem of object-oriented cost, and generally does not touch the abstract problem of object-oriented.
Flyweight uses the shared approach to reduce the number of objects in the system, thus reducing the memory pressure on the system caused by fine-grained objects.

Proxy:
Some objects, for some reason (such as high overhead for object creation, security control for some operations, or access outside the process), directly

Access brings a lot of trouble to users or system structures.
How can we manage and control the unique complexity of these objects without losing transparent operation objects? Adding an indirect layer is a common solution in software development.

Method.
Proxy intent: provide a proxy for other objects to control access to this object.

 

Summary of structural configuration modes:
The adapter mode focuses on the conversion interface and matches inconsistent interfaces with objects.

The Bridge Mode focuses on the separation of interfaces and their implementation, and supports multi-dimensional changes. (The interface may also be unstable)

The composite mode focuses on unified interfaces and converts "one-to-many" relationships into "one-to-one" relationships. (Container, complex structure)

The decorator mode focuses on stable interfaces and provides object extension functions on this premise.

The facade mode focuses on simplifying the scissors and simplifying the dependency between component systems and external customer programs.

The flyweight mode focuses on reserved interfaces and uses the sharing technology internally to optimize object storage.

The proxy mode focuses on the counterfeit interface and adds an indirect layer for flexible control.