Design patterns are reusable solutions to common design problems, allowing smoother, more A more efficientdevelopment process.
If we classify design patterns, they can be divided into the following three categories:
| Classification | Segmentation |
|---|---|
| creational pattern | Factory method pattern, abstract factory pattern, singleton pattern, builder pattern, prototype pattern |
| structural pattern | Adapter mode, decorator mode, proxy mode, appearance mode, bridge mode, combination mode, flyweight mode |
| behavioral patterns | Strategy pattern, Template method pattern, Observer pattern, Iterator pattern, Chain of responsibility pattern, Command pattern, Memo pattern, State pattern, Visitor pattern, Mediator pattern, Interpreter pattern |
This is a blogger who has compiled the 18 most popular common design patterns and distinguished them by color (blue represents the creation pattern mode, yellow indicates structural mode, green indicates behavioral mode) :
The text description is as follows:
- Abstract Factory(Abstract Factory): Family Creator - A group that manufactures related items.
- Builder(Builder): LEGO Master - Build objects step by step, keeping creation and appearance separate.
- Prototype(Prototype): Clone Maker - Create a copy of a fully prepared example.
- Singleton(Singleton): Unique - a special class with a unique instance.
- Adapter(Adapter): Universal plug - connects things with different interfaces.
- Bridge(Bridge): Functional connector - connects how an object works and what actions it performs.
- Composite(Composite): Tree Builder - Tree structures that form simple and complex parts.
- Decorator(Decorator): Customizer - adds functionality without changing the core of the object.
- Facade(Facade): One-stop shopping - Represent the entire system with a single, simplified interface.
- Flyweight(Flyweight): Space saver - efficiently share small, reusable items.
- Proxy(Proxy): Stand-in - represents another object, controlling access or operations.
- Chain of Responsibility(Chain of Responsibility): Request relay - Passing the request through a series of objects until it is processed.
- Command(Command): Task wrapper - converts the request into a ready object.
- Iterator(Iterator): Collection browser - access the elements in the collection one by one.
- Mediator(Mediator): Communication center - simplifies interaction between different classes.
- Memo (Memento) : Time Capsule - Capture and restore the state of an object.
- Observer(Observer): Newscaster - Notifies other objects of changes.
- Visitor (Visitor): Craft guest - Add new actions to the class without changing it.
If you want to learn more about its code implementation, you can refer to the relevant articles written by the blogger. Here is the link:
- 抽象工厂（Abstract Factory）： https://yanglinwei.blog.csdn.net/article/details/102784752
- 建造者（Builder）： https://yanglinwei.blog.csdn.net/article/details/102794053
- 原型（Prototype）： https://yanglinwei.blog.csdn.net/article/details/102799835
- 单例（Singleton）： https://yanglinwei.blog.csdn.net/article/details/102783344
- 适配器（Adapter）： https://yanglinwei.blog.csdn.net/article/details/102796299
- 桥接（Bridge）： https://yanglinwei.blog.csdn.net/article/details/79362158
- 组合（Composite）： https://yanglinwei.blog.csdn.net/article/details/79392726
- 装饰器（Decorator）： https://yanglinwei.blog.csdn.net/article/details/102800279
- 外观（Facade）： https://yanglinwei.blog.csdn.net/article/details/102797903
- 享元（Flyweight）： https://www.runoob.com/design-pattern/flyweight-pattern.html
- 代理（Proxy）： https://yanglinwei.blog.csdn.net/article/details/102792590
- 责任链（Chain of Responsibility）： https://yanglinwei.blog.csdn.net/article/details/79463094
- 命令（Command）： https://yanglinwei.blog.csdn.net/article/details/79370568
- 迭代器（Iterator）： https://yanglinwei.blog.csdn.net/article/details/79377026
- 中介者（Mediator）： https://www.runoob.com/design-pattern/mediator-pattern.html
- Memento（Memento）: https://www.runoob.com/design-pattern /memento-pattern.html
- 观察者（Observer）： https://yanglinwei.blog.csdn.net/article/details/102801621
- 访问者（Visitor）： https://yanglinwei.blog.csdn.net/article/details/79475821
Finally, the blogger posted the six principles that need to be followed in the above design patterns, which are also the essence of using design patterns:
- Open Close Principle: The Open Close Principle means that it is open for expansion and closed for modification. When the program needs to be expanded, the original code cannot be modified 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, which we will mention in the specific design later.
- Liskov Substitution Principle: Liskov Substitution Principle (
Liskov Substitution Principle LSP) is one of the basic principles of object-oriented design. The Liskov Substitution Principle says that wherever a base class can appear, a subclass can definitely appear.LSPis 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 be used in the base class. Add new behaviors based on classes. The Liskov substitution principle is a complement 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. - Dependence Inversion Principle: This is the basis of the opening and closing principle. The specific content: True interface programming relies on abstraction rather than concreteness.
- Interface Segregation Principle): This principle means: using multiple isolated interfaces is better than using a single interface . It also means reducing the coupling between classes. From here we can see that design patterns are actually a software design idea, starting from large-scale software architecture, for the convenience of upgrade and maintenance. So it appears many times above: reduce dependencies and reduce coupling.
- Demeter Principle (Demeter Principle): Why is it called the least known principle? That is to say: an entity should interact with other entities as little as possible function, making the system function modules relatively independent.
- Composite Reuse Principle: The principle is to use composition/aggregation as much as possible instead of inheritance.