A,
What are design patterns?
Written Definition:
Design pattern is a set of repeatedly used, most people know, classified, summarized code Design experience in programming. Design patterns are used to re-use code, make it easier for others to understand, and ensure code reliability.
Personal understanding: if programming is analogous to martial arts, understanding computer principles, mastering data structures and algorithms, and understanding a program can be counted as internal work. He who has deep internal skills will be able to learn martial arts easily. But light has internal merit, also stop at learning martial arts. To really coding, in addition to internal work, also need tricks. The design mode is a set of unique swordsmanship that Gof helped us extract and summarize from various moves.
Front-end and design patterns
At present, the development direction of the front-end is engineering, and the proportion of programming is increasing day by day. Design mode, as a necessary ability of object-oriented programming, is worth in-depth study of front-end students who want to improve their programming ability.
I would like to recommend several references for this article:
“Javascript Design Patterns and Development practices” book Design patterns – Raccoon design patterns -C Language Chinese
In addition, front-end students need to understand the difference between Javascript object-oriented and strongly typed language object-oriented when learning design patterns. After all, most design pattern examples are based on Java, so they need to understand how to implement encapsulation, inheritance and polymorphism in Java. Why Java has classes and interfaces is why you can read most of the design pattern articles on the market.
Two, object oriented six basic principles
Understanding the six basic principles of strongly typed OOP requires some understanding of the concepts of interfaces. A strongly typed language, in order to make the code with polymorphic characteristics (can flexibly switch calls class), in the statement above, we can declare some interface, the interface contains only the definition of parameters and methods, does not contain parameters and method of the concrete implementation (dependencies from dependence on a concrete class to rely on the abstract interface, which rely on an interface code, You can call any concrete class that implements the interface.
(For those of you who don’t understand interfaces, see dynamically typed languages and duck types in Section 1.1 of Javascript Design Patterns and Concurrent Practices.)
1. Principle of single responsibility
Single Responsibility Principle SRP definition: One interface is responsible for one Responsibility. Note: The more simple the responsibility, the less likely the interface will change and the more robust the code
2. Open and close principle
The Open – Closed – Principle OCP Principle
Definition: Entities should be open for extension and closed for modification. Note: Modifying existing features may introduce new bugs. So try to expand instead of modifying. However, the premise of realizing the open closed principle is that the entity itself has a fine-grained separation in design, such as meeting the single responsibility principle, which makes it easier to distinguish whether each interface is closed for modification or open for expansion.
3. Richter’s substitution principle
Liskov Diction Principle IN LSP
Definition: All references to a base class must be able to use objects of its subclasses. Note: Ensure the basic features of inheritance
4. Interface isolation principle
Interface Segregation Principle ISP
Definition: Use multiple specialized interfaces instead of a single master interface. Note: If an interface class with multiple methods serves two implementations, each of which relies on only some of the methods in the interface class, then the interface class should be split into two interface classes, ensuring that each implementation relies on a minimum number of interface methods.
5. Dependency inversion principle
Dependence Inversion Principle DIP
Definition: High level does not depend on low level, abstraction does not depend on details. Note: Try to raise the dependency between concrete objects to the dependency between their abstract interfaces. This ensures that even if a party changes, its dependent objects will not be affected as long as its abstract interface remains unchanged. To reduce the coupling
Demeter’s Rule
Law of Demter LoD
Also known as the Least Knowledge Principle LKP
Definition: An object should know the least about other objects. Note: If an object is dependent on seven or eight objects to implement a function, it is highly likely to change. As far as possible, there should be one dependency that handles the other dependencies associated with it, and the object itself only needs to depend on that one dependency.
Three, an overview of 23 design patterns
There are 23 design patterns, which can be divided into three categories:
- To create a type. Provides a mechanism for creating objects to improve reuse and flexibility.
- Structured. Describes the larger structures that objects can be assembled into
- Behavior model. Focus on effective communication between objects and delegating responsibilities
Brief introduction:
| type | Model name | function | The front-end scenario |
|---|---|---|---|
| Create a type | Factory method pattern | The parent class implements a factory method, and the subclass overrides the factory method to create concrete objects | Less common |
| Create a type | Abstract Factory pattern | Implement an abstract factory class, each concrete factory class selects a series of subclasses to create objects | Less common |
| Create a type | Builder model | Implement a builder class that determines the creation details of the product. | Less common |
| Create a type | The prototype pattern | The Clone method is provided in the class so that new objects can be created directly from existing objects | The JS objects themselves are based on prototypes |
| Create a type | The singleton pattern | At global scope, only one object instance is created | Global object, popover |
| structured | Adapter mode | Define an adapter class on top of the original class. Responsible for dealing with the compatibility problems of each call scenario and providing a unified interface externally | Bom event compatible, AXIOS source code |
| structured | The appearance model | Define a facade class on top of the original class. Simplify the original class call logic, external to provide a simple interface | Less common |
| structured | Decorator mode | The decorator class is used to accept an object as an input parameter, adding uniform new functionality to the object | ES6 decorator syntax, Mobx |
| structured | The proxy pattern | Define a proxy class on top of the original class. The proxy class is responsible for handling the invocation logic | Es6-proxy syntax, vuE3 responsive principle |
| structured | The bridge model | Separate the abstraction from the implementation in a class so that the two parts can vary independently. | Less common |
| structured | Portfolio model | The common classes are grouped in a tree structure, and the child nodes are recursively called from the parent node, so that the caller can operate on both the whole and the local | Component tree, virtual DOM tree |
| structured | The flyweight pattern | Split out sharable fine-grained units within a class that are shared across classes to reduce memory consumption | Less common |
| Behavior type | Command mode | If multiple execution interfaces need to be configured, you can configure command interfaces in a unified manner to map command interfaces to multiple execution interfaces | Action in state management |
| Behavior type | The mediation patterns | If there is many-to-many communication between similar objects, a mediation class is created that communicates with each object | Store in state management |
| Behavior type | Observer model | Both the message source and the consumer register with the observer class, which listens on the message source object and invokes the consumer object. | Vue2 response principle, RXJS |
| Behavior type | Chain of Responsibility model | To decompose a series of operations in a chain structure, the previous caller only needs to couple the next caller | Webpack middleware, Promise chain call |
| Behavior type | The state pattern | The state of the object is separated from the object, so that the state of the object can be flexibly changed without affecting the original object | Less common |
| Behavior type | The strategy pattern | The execution logic of multiple scenarios is placed in multiple policy classes to decouple the mapping logic between context and execution methods. | Form validation |
| Behavior type | Template method pattern | First determine the main framework of the class, postpone the implementation of specific steps to the subclass, by the subclass to rewrite the specific implementation of the need to change | Component life cycle |
| Behavior type | Visitor pattern | The data manipulation class is separated from the data structure class, so that the data manipulation mode can be expanded without changing the data structure class | Less common |
| Behavior type | Iterator pattern | Separate the access logic of the collection from the collection itself | Less common |
| Behavior type | Memo mode | If the historical state needs to be cached, the action of caching the state is placed inside the originator class, and the class that manages the snapshot only accepts the originator class to obtain the snapshot | react-memo |
| Behavior type | Interpreter mode | In addition to the current development language, define a set of syntax to simplify certain operations and implement them in less code | Less common |