What is a design pattern
A design pattern is a set of code design experiences that are used repeatedly, known to most people, and cataloged. In summary, it has nothing to do with specific language, it is a kind of thought.
Only by mastering object-oriented thinking can we better understand design patterns, and vice versa.
Design patterns are good programming methods summarized by programmers during the practice of software engineering.
There are 23 design patterns in total.
The essence of these 23 design patterns is the practical application of object-oriented design principles, and a full understanding of the encapsulation, inheritance and polymorphism of classes, as well as the association and combination relationships of classes.
(Recommended related video tutorials:java video)
Classification of design patterns
1. Creational pattern
Creative patterns (5 types): singleton pattern, factory method pattern, abstract factory pattern, builder pattern, prototype pattern.
2. Structural mode
Structural mode (7 types): adapter mode, decorator mode, proxy mode, appearance mode, bridge mode, combination mode, flyweight mode.
3. Behavioral patterns
Behavioral patterns (11 types): strategy pattern, template method pattern, observer pattern, iterative sub-pattern, chain of responsibility pattern, command pattern, memo pattern, State pattern, visitor pattern, mediator pattern, interpreter pattern.
Six principles of design patterns
General principles: Opening and closing principle
Open to extensions, closed to modifications. 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 the summary in one sentence is: in order to make the program scalable and 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
Do not have more than one reason for class changes, that is to say, each class should implement a single responsibility, otherwise the class should be split.
2. Liskov Substitution Principle
Anywhere a base class can appear, a subclass can definitely appear. The Liskov substitution principle is the cornerstone of inheritance 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 Richter substitution principle is a supplement to the "open-closed" principle. The key step in realizing the "open-closed" principle is abstraction. The inheritance relationship between base classes and subclasses is the specific implementation of abstraction, so the Liskov substitution principle is a specification for the specific steps to achieve abstraction. In the Liskov substitution principle, subclasses should try not to overwrite or overload methods of the parent class. Because the parent class represents a defined structure and interacts with the outside world through this standardized interface, subclasses should not destroy it casually.
3. Dependence Inversion Principle
Interface-oriented programming relies on abstraction rather than concreteness. When a concrete class is used when writing code, it does not interact with the concrete class, but with the upper interface of the concrete class.
4. Interface Segregation Principle
There are no methods in each interface that are not used by subclasses but must be implemented. If not, the interface must be split. It is better to use multiple isolated interfaces than to use a single interface (multiple interface methods combined into one interface).
5. Demeter 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 the public method. In this way, when the dependent class changes, the impact on the class will be minimal.
Another expression of the least-known principle is: only communicate with direct friends. As long as there is a coupling relationship between classes, it is called a friend relationship. Coupling is divided into dependence, association, aggregation, combination, etc. We call classes that appear in member variables, method parameters, and method return values direct friends. Local variables and temporary variables are not direct friends. We require that unfamiliar classes do not appear as local variables in the class.
6. Composite Reuse Principle
Try to use synthesis/aggregation first instead of inheritance.
Recommended tutorial:Getting started with java
The above is the detailed content of Briefly describe the concept of design patterns. For more information, please follow other related articles on the PHP Chinese website!