Summary of the series of learning notes for. NET Design Patterns

Spring yang

Design Pattern principles

The root cause of the use of the design pattern is the application changes, the code reuse rate is improved, and the software is more maintainability and scalability. The following principles must be followed: single primary responsibility, Open Closed Principal, dependency inversion, and Lishi replacement.

1. Single Responsibility Principle

For a class, there should be only one reason for his change. If a class has too many responsibilities, it is equivalent to coupling these responsibilities. A change in responsibilities may weaken or restrain the class from fulfilling other responsibilities. This coupling will lead to a fragile design. When a change occurs, the design will be broken unexpectedly.

2. Open and closed principles

Software entities (classes, modules, functions, etc.) should be extensible, but cannot be modified. That is to say, it is open to extensions and closed to modifications. In general, in the face of requirements, changes to the program are made by adding new Code, rather than changing the existing code.

3. Dependency inversion principle

Abstract should not be detailed. Details should depend on abstraction, that is, "interface programming rather than implementation programming ". It can also be understood that the high-level module should not depend on the underlying module, and both should be abstract; abstraction should not depend on details, and details should depend on abstraction.

4. Lee's replacement principle

Subclass must be able to replace their parent type. That is to say, during software development, if the child class replaces the parent class, the functional behavior of the program remains unchanged. Only when the child class can replace the parent class and the functions of the software unit are not affected can the parent class be reused. The Child class can also add new behaviors based on the parent class.

Three Design Models

Creation Mode
1. The Singleton mode solves the problem of the number of object objects. Apart from Singleton, other creation modes solve the coupling relationship brought about by new.
2. factory Method, Abstract Factory, and Builder all require an additional Factory class to instantiate the "variable object", while Prototype is a Prototype (a special Factory class) to clone the "variable object ".
3. if you encounter a "variable type", the initial design starts with FactoryMethod. When you encounter more complex changes, consider refactoring to the other three Factory models (Abstract Factory, Builder, prototype ).

Structural Mode
1. the Adapter mode focuses on the conversion interface, and the inconsistent interfaces are adapted and connected.
2. The Bridge Mode focuses on separating interfaces and their implementations, and supports multidimensional changes.
3. The Composite mode focuses on unified interfaces and converts "one-to-many" relationships into "one-to-one" relationships.
4. the Decorator mode focuses on stable interfaces and extends the functions of objects on this premise.
5. The Facade mode focuses on simplifying interfaces and simplifying the dependency between component systems and external customer programs.
6. The Flyweight mode focuses on reserved interfaces and uses the sharing technology internally to optimize object storage.
7. The Proxy mode focuses on the counterfeit interface and adds an indirect layer for flexible control.

Behavior mode
1. The Template Method mode encapsulates the algorithm structure and supports algorithm substep changes.
2. The Strategy Mode focuses on encapsulating algorithms and supports algorithm changes.
3. State mode encapsulates State-related behaviors and supports State changes.
4. Memento mode focuses on encapsulating object state changes and supports state saving/recovery
5. The Mediator mode encapsulates interaction between objects and supports object interaction changes.

6. The Chain Of Responsibility model focuses on encapsulating Object Responsibility and supports change Of Responsibility
7. The Command mode encapsulates requests as objects and supports request changes.
8. The Iterator mode encapsulates the internal structure of the collection object and supports collection changes.
9. The Interpreter mode encapsulates changes in specific fields and supports frequent changes in domain issues
10. The Observer mode encapsulates object notifications and supports communication object changes.
11. The Visitor mode encapsulates object operation changes and supports dynamic addition of new operations for the class hierarchy at runtime.

Summary of application of design patterns:

1. The design mode is based on the object's system change point, where there is a change point, and where the design mode is applied.

2. The design pattern should be obtained in an evolutionary manner, and the change points of the system can be precisely located only after constant evolution.

3. the design model cannot be a pattern for the purpose of pattern. It is a soft force of software design, rather than a standard, and should not exaggerate the role of the design pattern.

Comparison of various modes

Design Mode	Degree of use	Application Level	Introduction time	Structural Complexity
Abstract Factory	Relatively common	Application-level	Design Time	Relatively complex
Builder	Average	Code-level	Encoding time	Average
Factory Method	Very common	Code-level	Encoding time	Simple
Prototype	Not commonly used	Application-level	Encoding and refactoring	Relatively simple
Singleton	Very common	Code-level and application-level	Design and encoding	Simple
Adapter	Average	Code-level	Reconstruction	Average
Bridge	Average	Code-level	Design and encoding	Average
Composite	Relatively common	Code-level	Encoding and refactoring	Relatively complex
Decorator	Average	Code-level	Reconstruction	Relatively complex
Facade	Very common	Application and architecture	Design and encoding	Simple
Flyweight	Not commonly used	Code-level and application-level	Design Time	Average
Proxy	Relatively common	Application and architecture	Design and encoding	Simple
Chain of Resp.	Not commonly used	Application and architecture	Design and encoding	Relatively complex
Command	Relatively common	Application-level	Design and encoding	Relatively simple
Interpreter	Not commonly used	Application-level	Design Time	Relatively complex
Iterator	Average	Code-level and application-level	Encoding and refactoring	Relatively simple
Mediator	Average	Application and architecture	Encoding time and weight