I. Introduction
Today's field of software development is rapidly evolving, and software systems are becoming more and more complex. In this process, in the face of ever-changing requirements and business scenarios, how to complete software development quickly and efficiently has become an important issue. As a widely used solution, design patterns represent best practices. These solutions are the result of trial and error by numerous software developers over a considerable period of time and are usually adopted by experienced object-oriented software developers.
A design pattern is a set of code design experiences that are repeatedly used, known to most people, and summarized. Design patterns are used to reuse code, make code easier to understand by others, and ensure code reliability. There is no doubt that design patterns are win-win for oneself, others, and the system. Design patterns make code compilation truly engineering. Design patterns are the cornerstone of software engineering, just like the bricks and stones of a building.
Reasonable use of design patterns in the project can perfectly solve many problems. Each pattern has a corresponding principle to correspond to it in reality. Each pattern describes a problem that occurs repeatedly around us, and the problem. The core solution, which is why design patterns can be widely used.
2. What is a design pattern
Define Design Patterns
Design pattern is an empirical method to solve specific problems after years of practice and summarization in software development. It is a reusable solution that helps developers avoid common problems when designing software and improves the quality and maintainability of software.
GOF Gang of Four
In 1994, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides co-authored a book called Design Patterns - Elements of Reusable Object-Oriented Software (Chinese translation: Design Patterns - Reusable Object-Oriented Software Elements) , which introduced the concept of design patterns in software development for the first time.
The four authors are collectively called GOF (Gang of Four) . The design patterns they proposed are mainly based on the following object-oriented design principles.
- Program to the interface instead of the implementation.
- Prefer object composition over inheritance.
Goals of Design Patterns
The goals of design patterns mainly include the following points:
- Reduce coupling: By using design patterns, various modules in the system can be decoupled to improve system maintainability and scalability.
- Improve reusability: Design patterns provide some general solutions that can help us avoid reinventing the wheel and improve code reusability.
- Improves code readability: Design patterns provide a common language and structure that makes code easier to understand and read.
- Code maintainability: Because each module is decoupled, the code is easier to maintain.
- Error Reduction: Using design patterns can reduce the error rate of your code as these patterns are proven best practices that help avoid some common mistakes.
- Efficiency: Design patterns have been widely recognized, so they have been optimized and optimized to improve the efficiency and performance of the code.
3. Six principles of design patterns
Design patterns are guided by strict principles that help developers build high-quality, maintainable, and reusable software systems. Here are six design principles
1. Single Responsibility Principle (SRP)
The Single Responsibility Principle means that a class is only responsible for the corresponding responsibilities in one functional area, or it can be simply said that a class only does one thing. If the function responsible for a class is too complex, it should be split into multiple classes, and each class is only responsible for the corresponding responsibility in one functional area, so as to realize code reuse and maintenance.
2. Open and Closed Principle (OCP)
The open-closed principle means that a software entity should be open for extension and closed for modification. That is to say, when designing a system, you should try to avoid modifying the original code, but implement new functions through extension.
3. Liskov Substitution Principle (LSP)
The Liskov Substitution Principle is one of the basic principles of object-oriented design. The Liskov substitution principle means that wherever a base class can appear, a subclass must appear. That is to say, the subclass can replace the parent class anywhere in the program, and the logical behavior of the program is guaranteed to remain unchanged. LSP 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 based on the base class. Behavior.
4. Dependency Inversion Principle (DIP)
This principle is the basis of the principle of opening and closing. The principle of dependency inversion means that high-level modules should not depend on low-level modules, and both should depend on abstractions. Abstract interfaces should not depend on concrete implementations, and concrete implementations should depend on abstract interfaces. To put it simply, it is programming for the interface. The program directly calls the interface instead of calling the implementation class, which reduces the coupling between the client and the implementation module.
5. Interface Segregation Principle (ISP)
The interface isolation principle refers to the separation and isolation of methods of different types in the interface, so that the client does not need to implement the methods it does not need. In other words, the dependence of a class on another class should be established on the smallest interface, and the interface should be split into smaller and more specific interfaces as much as possible, so that the interface only contains the methods required by the client.
6. Law of Demeter (LoD)
An object should interact with other objects as little as possible, and reduce the coupling between classes as much as possible. Also known as the principle of least knowledge, least knowledge means that an object knows as little as possible about other objects.
Fourth, the classification of design patterns
Design patterns can be divided into three types: creational patterns, structural patterns, and behavioral patterns.
Creational patterns
This type of pattern provides a mechanism for creating objects, which can improve the flexibility and reusability of existing code.
| serial number | type | describe |
|---|---|---|
| 1 | Factory Method Pattern | Define an interface for creating objects, and let its subclasses decide which factory class to instantiate. The factory mode delays the creation process to subclasses. |
| 2 | Abstract Factory Pattern | Provides an interface for creating a series of related or interdependent objects without specifying their concrete classes. |
| 3 | Singleton Pattern | Ensures that there is only one instance of a class and provides a global access point to it. |
| 4 | Builder Pattern | Separating a complex build from its representation allows the same build process to create different representations. |
| 5 | Prototype Pattern | Use prototype instances to specify the type of object to be created, and create new objects by copying these prototypes. |
structural pattern
These patterns describe how to assemble objects and classes into larger structures while keeping the structure flexible and efficient.
| serial number | type | describe |
|---|---|---|
| 1 | Adapter Pattern | Convert the interface of a class to another interface that the client wants. The Adapter pattern enables classes that would otherwise not work together due to incompatible interfaces to work together. |
| 2 | Bridge Pattern | Separate the abstraction from the implementation so that they can both vary independently. |
| 3 | Composite Pattern¶ | Group objects into tree structures to represent "part-whole" hierarchies. Composite mode enables users to use a single object and a composite object in a consistent manner. |
| 4 | Decorator Pattern | Dynamically add some additional responsibilities to an object. In terms of adding functionality, the decorator pattern is more flexible than generating subclasses. |
| 5 | Facade Pattern | Provides a consistent interface for a set of interfaces in a subsystem, Facade mode defines a high-level interface that makes the subsystem easier to use. |
| 6 | Flyweight Pattern | Use sharing technology to efficiently support large numbers of fine-grained objects. |
| 7 | Proxy Pattern | Provides a proxy for other objects to control access to this object. |
behavioral model
These patterns are responsible for efficient communication and delegation of responsibilities between objects.
| serial number | type | describe |
|---|---|---|
| 1 | Chain of Responsibility Pattern | Avoid coupling the request sender and receiver together, make it possible for multiple objects to receive the request, connect these objects into a chain, and pass the request along this chain until an object processes it. |
| 2 | Command Pattern | Encapsulates a request into an object, allowing you to parameterize clients with different requests. |
| 3 | Iterator Pattern | Provides a way to sequentially access the elements of an aggregate object without exposing the object's internal representation. |
| 4 | Mediator Pattern | An intermediary object is used to encapsulate a series of object interactions. The intermediary makes objects do not need to explicitly refer to each other, so that the coupling is loose, and the interaction between them can be changed independently. |
| 5 | Memento Pattern | Capture the internal state of an object and save that state outside the object without breaking encapsulation. |
| 6 | Observer Pattern | Define a one-to-many dependency relationship between objects. When the state of an object changes, all objects that depend on it will be notified and automatically updated. |
| 7 | State Pattern | Allows an object to change its behavior when its internal state changes, and the object appears to modify its class. |
| 8 | Strategy Pattern | Define a series of algorithms, encapsulate them one by one, and make them interchangeable. |
| 9 | Template Method Pattern | Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. The template method allows subclasses to define some specific steps of an algorithm without changing the structure of the algorithm. |
| 10 | Visitor Pattern | It mainly separates the data structure from the data operation, so that new operations can be added without changing the object structure. |
| 11 | Interpreter Pattern | Defines the grammar of a language and builds an interpreter to interpret sentences in the language. The scope of application is narrow. |
V. Conclusion
Creation is not easy. If this article is helpful to you, please like, bookmark and pay attention. Your support and encouragement are the biggest motivation for my creation.
