【设计模式】常用设计模式-总结

一.常见的设计模式

1. 创建型模式（Creational Patterns）：

   • 工厂模式（Factory Pattern）
   • 抽象工厂模式（Abstract Factory Pattern）
   • 单例模式（Singleton Pattern）
   • 原型模式（Prototype Pattern）
   • 建造者模式（Builder Pattern）

2. 结构型模式（Structural Patterns）：

   • 适配器模式（Adapter Pattern）
   • 桥接模式（Bridge Pattern）
   • 组合模式（Composite Pattern）
   • 装饰模式（Decorator Pattern）
   • 外观模式（Facade Pattern）
   • 享元模式（Flyweight Pattern）
   • 代理模式（Proxy Pattern）

3. 行为型模式（Behavioral Patterns）：

   • 责任链模式（Chain of Responsibility Pattern）
   • 命令模式（Command Pattern）
   • 解释器模式（Interpreter Pattern）
   • 迭代器模式（Iterator Pattern）
   • 中介者模式（Mediator Pattern）
   • 备忘录模式（Memento Pattern）
   • 观察者模式（Observer Pattern）
   • 状态模式（State Pattern）
   • 策略模式（Strategy Pattern）
   • 模板方法模式（Template Method Pattern）
   • 访问者模式（Visitor Pattern）

二.基本概念

1. 工厂模式（Factory Pattern）：通过定义一个创建对象的接口，由子类决定实例化哪个具体类。适用于需要创建对象，但不希望客户端直接与具体类耦合的场景。

2. 抽象工厂模式（Abstract Factory Pattern）：提供一个接口用于创建相关或依赖对象的家族，而不需要指定具体的类。适用于需要创建一组相关对象的场景，且希望将创建逻辑与使用者分离。

3. 单例模式（Singleton Pattern）：保证一个类只有一个实例，并提供全局访问点。适用于需要全局唯一实例的场景，如日志记录器、数据库连接等。

4. 原型模式（Prototype Pattern）：通过复制现有对象来创建新对象，避免了重复构造过程，提高了对象创建的效率。

5. 建造者模式（Builder Pattern）：将一个复杂对象的构建过程与其表示分离，通过一步一步构建的方式创建对象。适用于构建复杂对象，且构建过程需要灵活配置的场景。

6. 适配器模式（Adapter Pattern）：将一个类的接口转换成客户端所期望的另一个接口。适用于需要将不兼容接口转换为兼容接口的场景。

7. 桥接模式（Bridge Pattern）：将抽象部分与其具体实现部分分离，使它们可以独立地变化。适用于存在多种变化维度的场景，可以提高系统的可扩展性。

8. 组合模式（Composite Pattern）：将对象组合成树状结构，以表示部分-整体的层次结构。适用于需要表示对象的整体-部分层次结构，并且希望对整体和部分都进行一致的操作。

9. 装饰模式（Decorator Pattern）：动态地给对象添加额外的职责，而不影响其原始类。适用于需要在不修改原始类的情况下，给对象添加功能或职责的场景。

10. 外观模式（Facade Pattern）：为复杂子系统提供一个简单统一的接口，隐藏了子系统的复杂性，使其易于使用。适用于需要简化对外接口的场景。

11. 享元模式（Flyweight Pattern）：共享对象以减少内存使用和提高性能。适用于需要创建大量相似对象的场景，通过共享对象来节省内存。

12. 代理模式（Proxy Pattern）：为其他对象提供一个代理以控制对其的访问。适用于需要在访问对象时添加额外的控制逻辑的场景，如延迟加载、权限控制等。

13. 责任链模式（Chain of Responsibility Pattern）：将请求的发送者和接收者解耦，通过一条链传递请求，直到有一个对象能够处理它为止。适用于需要动态确定处理请求的对象集合的场景。

14. 命令模式（Command Pattern）：将请求封装成对象，以便在不同的请求发送者和接收者之间进行解耦。适用于需要将请求参数化、排队或记录请求操作的场景。

15. 解释器模式（Interpreter Pattern）：定义了一个语言的文法，并定义该语言的解释器。适用于需要解释和执行一些特定规则或语言的场景。

16. 迭代器模式（Iterator Pattern）：提供一种顺序访问聚合对象中各个元素的方式，而不暴露其内部表示。适用于需要遍历聚合对象并访问其中元素的场景。

17. 中介者模式（Mediator Pattern）：通过引入一个中介对象，将系统中多个对象之间的交互进行解耦。适用于需要集中管理多个对象之间交互的场景。

18. 备忘录模式（Memento Pattern）：在不违反封装原则的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。适用于需要保存和恢复对象状态的场景。

19. 观察者模式（Observer Pattern）：定义了一种一对多的依赖关系，使得多个观察者对象同时监听一个主题对象的状态变化。适用于需要实现对象间的松耦合、一对多的依赖关系的场景。

20. 状态模式（State Pattern）：允许对象在其内部状态发生改变时改变其行为。适用于对象行为随状态改变而改变的场景，可以避免使用大量的条件判断语句。

21. 策略模式（Strategy Pattern）：定义了一系列的算法，并将其封装起来，使其可以相互替换。适用于需要在运行时根据不同情况选择不同算法的场景。

22. 模板方法模式（Template Method Pattern）：定义了一个算法的骨架，将某些步骤延迟到子类中实现。适用于具有相似算法结构，但其中某些步骤有所不同的场景。

23. 访问者模式（Visitor Pattern）：封装一些作用于某种数据结构中的各元素的操作，使其可以在不改变元素类的前提下，定义新的操作。适用于需要对数据结构中的元素进行不同操作的场景。

三.特点与适用场景

设计模式	特点	适用场景
工厂模式（Factory Pattern）	封装了对象的创建过程，隐藏了具体实现，通过工厂方法来创建对象。	- 当客户端需要创建对象，但不需要知道具体实现类时 - 当创建对象的过程比较复杂，需要封装起来以便复用和管理时<br>- 当需要使用相同的接口创建一族相关对象时
抽象工厂模式（Abstract Factory Pattern）	提供了一个接口用于创建相关或依赖对象的家族，不需要指定具体的类。	- 当有多个相关的产品系列需要创建时 - 当系统需要独立于产品的创建、组合和表示时
单例模式（Singleton Pattern）	保证一个类只有一个实例，并提供全局访问点。	- 当需要确保一个类只有一个实例时 - 当全局访问点能够提供对该实例的访问时
原型模式（Prototype Pattern）	通过复制现有对象来创建新对象，避免了重复的构造过程。	- 当对象的创建过程较为复杂，且需要避免重复构造时<br>- 当需要动态添加或删除对象时
建造者模式（Builder Pattern）	将一个复杂对象的构建过程与其表示分离，通过一步一步构建的方式创建对象。	- 当创建复杂对象的构造过程比较繁琐且多样化时 - 当需要创建多个相似对象时
适配器模式（Adapter Pattern）	将一个类的接口转换成客户端所期望的另一个接口。	- 当需要将已存在的类与其他类协同工作时 - 当需要使用某个已存在的类，但其接口与需求不匹配时
桥接模式（Bridge Pattern）	将抽象部分与其具体实现部分分离，使它们可以独立地变化。	- 当需要将抽象和实现部分分离，以便独立地变化和扩展时<br>- 当需要在多个维度上进行扩展时
组合模式（Composite Pattern）	将对象组合成树状结构，以表示部分-整体的层次结构。	- 当需要表示对象的整体-部分层次结构，并希望对整体和部分都进行一致的操作时 - 当需要忽略对象与对象集合的不同，统一对待时
装饰模式（Decorator Pattern）	动态地给对象添加额外的职责，而不影响其原始类。	- 当需要在不修改原始类的情况下，给对象添加功能或职责时<br>- 当需要通过多个对象进行功能组合时
外观模式（Facade Pattern）	为复杂子系统提供一个简单统一的接口，隐藏了子系统的复杂性，使其易于使用。	- 当需要简化对外接口的场景 - 当需要对复杂子系统进行解耦，提高系统的灵活性和可维护性时
享元模式（Flyweight Pattern）	共享对象以减少内存使用和提高性能。	- 当需要创建大量相似对象时，并且对象的状态可在外部环境中共享和复用时
代理模式（Proxy Pattern）	为其他对象提供一个代理以控制对其的访问。	- 当需要在访问对象时添加额外的控制逻辑时 - 当需要延迟创建或访问对象时
责任链模式（Chain of Responsibility Pattern）	将请求的发送者和接收者解耦，通过一条链传递请求，直到有一个对象能够处理它。	- 当需要动态确定处理请求的对象集合的场景 - 当需要按顺序处理请求，但不明确知道哪个对象能处理请求时
命令模式（Command Pattern）	将请求封装成对象，以便在不同的请求发送者和接收者之间进行解耦。	- 当需要将请求参数化、排队或记录请求操作的场景 - 当需要支持撤销和重做操作时
解释器模式（Interpreter Pattern）	定义了一个语言的文法，并定义该语言的解释器。	- 当需要解释和执行一些特定规则或语言的场景时
迭代器模式（Iterator Pattern）	提供一种顺序访问聚合对象中各个元素的方式，而不暴露其内部表示。	- 当需要遍历聚合对象并访问其中元素的场景时 - 当需要对不同聚合对象提供统一的访问方式时
中介者模式（Mediator Pattern）	通过引入一个中介对象，将系统中多个对象之间的交互进行解耦。	- 当需要集中管理多个对象之间交互的场景时 - 当系统中对象之间的交互逻辑复杂且紧密耦合时
备忘录模式（Memento Pattern）	在不违反封装原则的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。	- 当需要保存和恢复对象状态的场景 - 当需要实现撤销和恢复功能时
观察者模式（Observer Pattern）	定义了一种一对多的依赖关系，使得多个观察者对象同时监听一个主题对象的状态变化。	- 当需要实现对象间的松耦合、一对多的依赖关系的场景时 - 当一个对象状态变化需要通知其他对象时
状态模式（State Pattern）	允许对象在其内部状态发生改变时改变其行为。	- 当对象行为随状态改变而改变的场景 - 当需要避免使用大量的条件判断语句时
策略模式（Strategy Pattern）	定义了一系列的算法，并将其封装起来，使其可以相互替换。	- 当需要在运行时根据不同情况选择不同算法的场景时
模板方法模式（Template Method Pattern）	定义了一个算法的骨架，将某些步骤延迟到子类中实现。	- 当具有相似算法结构，但其中某些步骤有所不同的场景时 - 当需要通过子类来扩展和实现算法的某些特定步骤时
访问者模式（Visitor Pattern）	封装一些作用于某种数据结构中的各元素的操作，使其可以在不改变元素类的前提下，定义新的操作。	- 当需要对数据结构中的元素进行不同操作，且不希望改变元素类的结构时