Article reprint source : click to open the link
Design patterns fall into three categories:
There are five types of creational patterns : factory method pattern, abstract factory pattern, singleton pattern, builder pattern, and prototype pattern.
There are seven structural patterns : adapter pattern, decorator pattern, proxy pattern, appearance pattern, bridge pattern, composition pattern, and flyweight pattern.
There are eleven behavioral patterns : strategy pattern, template method pattern, observer pattern, iteration sub pattern, responsibility chain pattern, command pattern, memorandum pattern, state pattern, visitor pattern, mediator pattern, and interpreter pattern.
In fact, there are two types: concurrent mode and thread pool mode.
Six principles of design patterns:
General Principle - Open-Closed Principle
Open for extension, closed for modification. When the program needs to be expanded, the original code cannot be modified, but the original code must be expanded to achieve a hot-swappable effect. So one sentence summary is: in order to make the program expandable, easy to maintain and upgrade.
To achieve this effect, we need to use interfaces and abstract classes, etc. , we will mention this in the specific design later.
1. Single Responsibility Principle
There should not be more than one reason for a class to change, that is, each class should implement a single responsibility, otherwise the class should be split.
2. Liskov Substitution Principle
Wherever a base class can appear, a subclass must appear. The Liskov substitution principle is the cornerstone of inheritance and reuse. Only when the derived class can replace the base class and the function of the software unit is not affected, the base class can be truly reused, and the derived class can also add new ones on the basis of the base class. the behavior of.
The Liskov substitution principle is a complement to the "open-closed" principle. A key step in implementing the "open-closed" principle is abstraction. The inheritance relationship between the base class and the subclass is the concrete realization of abstraction, so the Liskov substitution principle is the specification of the concrete steps to realize abstraction. In the Liskov substitution principle, subclasses should try not to rewrite and overload the methods of the superclass. Because the parent class represents the defined structure and interacts with the outside world through this canonical interface, the subclass should not break it casually.
3. Dependence Inversion Principle
Interface-oriented programming relies on abstraction rather than concreteness. When writing code using a concrete class, it does not interact with the concrete class, but interacts with the upper-level interface of the concrete class.
4. Interface Segregation Principle
There is no method in each interface that subclasses cannot use but must implement. If not, the interface should be split. It is better to use multiple isolated interfaces than to use a single interface (an interface where multiple interface methods are grouped into one).
5. Demeter Principle (Least Knowing Principle) (Demeter Principle)
The less a class knows about the classes it depends on, the better. No matter how complex the dependent class is, the logic should be encapsulated inside the method and provided to the outside through public methods. In this way, when the dependent class changes, the class can be minimally affected.
Another way of expressing the principle of least knowing is: only communicate with immediate friends. As long as there is a coupling relationship between classes, it is called a friend relationship. Coupling is divided into dependency, association, aggregation, composition, etc. We call classes that appear as member variables, method parameters, and method return values direct friends. Local variables, temporary variables are not direct friends. We require unfamiliar classes not to appear in classes as local variables.
6. Composite Reuse Principle
Try to use composition/aggregation first instead of inheritance.