Overview of 23 Design Patterns

---

foreword

The importance of design patterns

Design patterns are the proposed solutions to various problems that exist in software design (meaning, no matter what kind of management system you do, there will be some common problems, and a solution is proposed, that is, design model)

Purpose of Design Patterns

Low coupling, high cohesion, maintainability, scalability, reusability, flexibility

---

Overview (to be updated)

creative mode

schema name	Article address
prototype mode	https://blog.csdn.net/Susan003/article/details/126203588
builder mode	(pending upgrade)
single-column mode	https://blog.csdn.net/Susan003/article/details/126214664
factory pattern	(pending upgrade)

Structural Pattern

schema name	Article address
adapter mode	https://blog.csdn.net/Susan003/article/details/126257995
decorator pattern	(pending upgrade)
bridge mode	https://blog.csdn.net/Susan003/article/details/126801611
Appearance Mode	(pending upgrade)
Combination mode	https://tanyongpeng.blog.csdn.net/article/details/126996168
flyweight pattern	https://blog.csdn.net/Susan003/article/details/126715006
proxy mode	https://blog.csdn.net/Susan003/article/details/126687565

behavioral model

schema name	Article address
Template mode	https://blog.csdn.net/Susan003/article/details/126634342
command mode	https://blog.csdn.net/Susan003/article/details/126684681
visitor pattern	https://tanyongpeng.blog.csdn.net/article/details/127053441
iterator pattern	(pending upgrade)
Observer pattern	(pending upgrade)
mediator model	(pending upgrade)
memo mode	https://blog.csdn.net/Susan003/article/details/126656452
Interpreter mode	(pending upgrade)
state mode	(pending upgrade)
strategy mode	(pending upgrade)
Chain of Responsibility Pattern	https://tanyongpeng.blog.csdn.net/article/details/127051711

Design Principles Core Ideas

1. Find out where changes may be needed in the application, separate them out and don't mix them with code that doesn't need to change

2. Program for the interface, not for the implementation

3. Strive for loosely coupled design between interacting objects

The Seven Principles of Design Patterns

Single Responsibility Principle

1. For classes, a class is only responsible for one responsibility. If class A is responsible for two different responsibilities, responsibility 1 and responsibility 2, when responsibility 1 needs to change and A changes, it may cause responsibility 2 execution errors, all need to be changed. The granularity of class A is decomposed into A1, A2

2. Single Responsibility Considerations and Details

3. Reduce class complexity, one class is responsible for one responsibility

4. Improve class readability and maintainability

5. Reduce risk from change

6. Usually, we should abide by the single responsibility principle. Only the logic is simple enough to violate the single responsibility principle at the code level; only the method data in the class is small enough to maintain the single responsibility principle at the method level.

Interface Segregation Principle

1. If class A needs method 1 in interface 1, class B needs method 2 in interface 1, and class C needs methods 1 and 2 in interface 1, we need to split the interface and split interface 1 into two interfaces , class AB implements the interface of the required method, then class C implements interface 1 and interface 2

Dependency Inversion Principle

1. The underlying modules should have abstract classes or interfaces, or both, the program stability is better, and the declared types of variables should be classes or interfaces as much as possible, so that there is a buffer layer between our variable references and actual objects, which is beneficial to Program expansion and optimization

Liskov Substitution Principle

1. Inheritance includes such a meaning: all the methods in the parent class that have already implemented the number are actually setting rules and contracts. Although it does not mandate that all subclasses must follow these contracts, if the subclasses have implemented these Any modification of the method will cause damage to the entire inheritance

2. Inheritance not only brings convenience to program design, but also brings disadvantages. For example, the use of inheritance will bring intrusiveness to the program, reduce the portability of the program, and increase the coupling between objects. Inheritance, when this class needs to be modified, all subclasses must be considered, and all functions involving subclasses may fail

3. Personal understanding: Class B inherits class A. When class B rewrites the methods in class A, this will change the original meaning of the original method of class A. Class B can be raised one level, that is, father and son become brothers, let them To inherit a base class together, write the basic methods and member variables into the base, so that class B can write its own methods, if class B needs to use the methods in class A, define the variable class A in the current class B, and instantiate it A method is called after class A, which is called combination

Open closed principle (ocp principle)

1. The Open Closed Principle is the most basic and important design principle in programming

2. A software entity such as classes, modules, and functions should be open for extension, closed for modification, framed with abstractions, and extended with implementation details

3. When the software needs to change, try to achieve the change by extending the behavior of the software entity, rather than modifying the existing code to achieve the change

4. Follow other principles in programming, and the purpose of using design patterns is to follow the open-closed principle

5. Personal understanding: to improve the scalability of the program, there is no need to change the code of the caller (user), and it can be used as it was originally used. The change is that the passed objects need to be changed.

Law of Demeter

1. An object should have minimal knowledge about other objects

2. The closer the class is to the class, the greater the degree of coupling

3. The Law of Demeter is also known as the principle of least knowledge, that is, the less a class knows about the classes it depends on, the better. No matter how complex the dependent classes are, try to encapsulate the logic inside the class. In addition to providing public methods to the outside world, Do not disclose any information to the outside world

4. There is a simpler definition of the Law of Demeter: only communicate with direct friends

5. Direct friends: Every object will have a coupling relationship with other objects. As long as there is a coupling relationship between two objects, we say that these two objects are friends. There are many ways of coupling, such as dependency, association, combination, and aggregation. etc., in which we call the classes that appear in member variables, method parameters, and method return values ​​as direct friends, while the classes appearing in local variables are not direct friends, that is, it is best not to appear in the form of local variables. inside the class

6. The core of the Law of Demeter is to reduce the coupling between classes

7. But note: Since each class reduces unnecessary dependencies, the Law of Demeter only requires reducing the coupling relationship between classes, not requiring no dependencies at all

Synthetic reuse principle

1. The principle is to try to use composition/aggregation instead of inheritance

end!