设计模式是一种解决常见编程问题的经验总结，提供了代码的可重用性、可扩展性和可维护性。常见的设计模式有23个，主要分为三大类：创建型模式、结构型模式和行为型模式。下面是这三类设计模式的详细分类和讲解：

一、创建型模式

创建型模式主要处理对象的创建过程，提供了不同的方式来控制对象的创建，以提高灵活性和可复用性。

1. 单例模式（Singleton Pattern）

保证一个类仅有一个实例，并提供全局访问点。

• 使用场景：资源管理器、日志系统、数据库连接池等。
• 优点：减少内存开销，避免多次创建实例。
• 缺点：容易造成全局状态，使得代码难以测试。

2. 工厂方法模式（Factory Method Pattern）

定义一个用于创建对象的接口，但让子类决定要实例化的类。
-使用场景：当一个类不知道它所需要创建的对象的具体类型时。
-优点：提高灵活性，使代码依赖于抽象而非具体类。
-缺点：增加类的数量，增加系统复杂性。

3. 抽象工厂模式（Abstract Factory Pattern）

提供一个接口，用于创建一系列相关或依赖的对象，而无需指定具体的类。
-使用场景：当系统需要与多个相关联的产品族打交道时。
-优点：易于扩展，满足"开放-关闭"原则。
-缺点：复杂度较高，扩展困难。

4. 建造者模式（Builder Pattern）

将一个复杂对象的构建过程与其表示分离，使得同样的构建过程可以创建不同的表示。

• 使用场景：构建复杂对象时，如HTML生成器、SQL查询构建器等。
• 优点：使得创建过程更加清晰，可拆分步骤。
• 缺点：产品变化多时，建造者类可能会变得庞大。

5. 原型模式（Prototype Pattern）

通过复制已有的实例来创建新对象，而不是通过实例化类来创建。

• 使用场景：当对象的创建开销较大，且需要大量相似对象时。
• 优点：避免重复初始化。
• 缺点：深拷贝和浅拷贝的处理可能较复杂。

二、结构型模式

结构型模式关注类和对象的组合，主要目的是通过继承或组合的方式来获得新的功能。

1. 适配器模式（Adapter Pattern）

将一个类的接口转换成客户希望的另外一个接口，使得原本接口不兼容的类可以一起工作。

• 使用场景：当现有类的接口与需求不符时，如将老系统接口适配新系统。
• 优点：复用已有代码，增强代码兼容性。
• 缺点：增加了系统的复杂性。

2. 桥接模式（Bridge Pattern）

将抽象部分与实现部分分离，使它们可以独立变化。

• 使用场景：当一个类具有多个维度的变化时（如设备和操作系统）。
• 优点：可以独立扩展抽象和实现部分。
• 缺点：增加了系统的理解和设计难度。

3. 组合模式（Composite Pattern）

将对象组合成树形结构以表示“部分-整体”的层次结构，使得用户对单个对象和组合对象的使用具有一致性。

• 使用场景：当系统需要表示树形结构时，如文件系统。
• 优点：简化了客户端代码。
• 缺点：使得设计更加复杂。

4. 装饰器模式（Decorator Pattern）

动态地给对象添加新的功能，而不改变其结构。

• 使用场景：需要动态地为对象增加功能，如给窗体增加滚动条。
• 优点：灵活性高，不改变原有类的情况下扩展功能。
• 缺点：增加了系统的复杂性。

5. 外观模式（Facade Pattern）

提供一个统一的接口，来访问子系统中的一群接口，使得子系统更加容易使用。

• 使用场景：当系统复杂，且需要对外提供简化的接口时。
• 优点：简化了复杂系统的调用，降低了客户对子系统的依赖。
• 缺点：可能掩盖了子系统的真正复杂性。

6. 享元模式（Flyweight Pattern）

通过共享已经存在的对象，减少创建对象的数量，从而减少内存开销。

• 使用场景：大量相似对象存在，且内存占用大时，如文本编辑器中的字符对象。
• 优点：减少内存消耗，提高性能。
• 缺点：增加了系统复杂性。

7. 代理模式（Proxy Pattern）

为其他对象提供一种代理，以控制对这个对象的访问。

• 使用场景：远程代理、虚拟代理、保护代理等场景。
• 优点：控制访问权限，降低开销。
• 缺点：引入了间接性，增加了复杂度。

三、行为型模式

行为型模式关注对象之间的通信和协作，目的是使对象之间的交互更加灵活。

1. 责任链模式（Chain of Responsibility Pattern）

将请求沿着处理链传递，直到有一个对象处理它。

• 使用场景：需要多个对象处理请求，但处理者不确定时。
• 优点：降低了请求发送者和接受者之间的耦合度。
• 缺点：处理链过长时，性能可能受到影响。

2. 命令模式（Command Pattern）

将请求封装成对象，以便可以使用不同的请求、队列或日志来参数化其他对象。

• 使用场景：实现撤销操作、事务管理等。
• 优点：解耦请求发送者和接收者。
• 缺点：增加了系统的复杂性。

3. 解释器模式（Interpreter Pattern）

给定一种语言，定义它的文法表示，并定义一个解释器来解释这些表达式。

• 使用场景：编译器、规则引擎等。
• 优点：灵活，易于扩展文法。
• 缺点：文法复杂时，难以维护。

4. 迭代器模式（Iterator Pattern）

提供一种方法顺序访问一个集合对象中的各个元素，而不暴露其内部表示。

• 使用场景：遍历集合对象时。
• 优点：使得集合遍历统一。
• 缺点：额外的开销。

5. 中介者模式（Mediator Pattern）

通过一个中介者对象来封装对象之间的交互，使得对象不需要显式地相互引用，降低了耦合度。

• 使用场景：多个对象间交互复杂时，如GUI组件之间的通信。
• 优点：减少了对象之间的依赖关系。
• 缺点：中介者本身可能会变得复杂。

6. 备忘录模式（Memento Pattern）

在不破坏封装的前提下，捕获对象的内部状态，以便在未来可以恢复它。

• 使用场景：实现撤销操作时。
• 优点：实现了对象状态的快照。
• 缺点：可能导致内存开销大。

7. 观察者模式（Observer Pattern）

定义对象间的一对多依赖关系，当一个对象状态改变时，所有依赖它的对象都会得到通知并自动更新。

• 使用场景：事件监听机制，GUI框架等。
• 优点：松散耦合，灵活性高。
• 缺点：如果观察者太多，通知可能会导致性能问题。

8. 状态模式（State Pattern）

允许对象在其内部状态发生改变时改变其行为，看起来像是修改了它的类。

• 使用场景：对象的行为随状态变化而变化时，如状态机。
• 优点：将状态与行为封装在一个类中，减少条件语句。
• 缺点：状态较多时，类的数量可能会增加。

9. 策略模式（Strategy Pattern）

定义一系列算法，并将它们封装起来，使它们可以互相替换，且算法的变化不会影响使用算法的客户。

• 使用场景：当算法有多种实现方式
• 优点：符合“开放-关闭”原则，易于扩展。
• 缺点：客户端需要了解不同的策略类。

10. 模板方法模式（Template Method Pattern）

定义算法的骨架，并允许子类在不改变算法结构的情况下重新定义某些步骤。

• 使用场景：固定算法流程，但部分步骤需要可扩展时。
• 优点：复用代码，易于维护。
• 缺点：灵活性受限。

11. 访问者模式（Visitor Pattern）

访问者模式用于将数据结构与操作解耦。通过在访问者中定义新的操作，可以避免修改数据结构。该模式允许你在不改变元素类的前提下，定义作用于这些类的新操作。

• 使用场景：需要对一个对象结构中的元素执行许多不同的操作，但又不希望因为频繁增加新操作而修改这些类时。
  结构：访问者模式有两个关键角色：
• 优点：增加新的操作非常简单，只需增加新的访问者类即可。符合单一职责原则，将不同操作的实现与对象结构的实现分离。
• 缺点：如果对象结构经常改变，添加新元素会比较麻烦，因为所有的访问者类都需要更新。

这些设计模式是软件开发中常用的工具，通过合理的使用可以显著提高系统的灵活性、扩展性和可维护性。在实际开发中，选择合适的模式需要根据具体问题场景来判断。

参考文档
https://medium.com/nerd-for-tech/design-patterns-introduction-7022b8d384c6