设计模式及其组合应用全景清单

创建型模式 (5种)

1. 单例模式 (Singleton)

• 核心解决思路：确保一个类只有一个实例，并提供全局访问点。
• 典型应用场景：配置文件管理、线程池、数据库连接池、日志对象、缓存系统。
• 核心痛点：避免重复创建消耗资源的对象，统一控制对共享资源的访问。
• 简介：通过私有化构造器、静态方法和静态变量来控制实例化过程，确保全局唯一性。

2. 工厂方法模式 (Factory Method)

• 核心解决思路：定义一个创建对象的接口，但让子类决定实例化哪一个类。
• 典型应用场景：日志记录器（可创建文件/数据库日志）、连接器工厂、UI主题组件工厂。
• 核心痛点：客户端需要知道具体类名才能创建对象，导致耦合度高。
• 简介：将对象创建延迟到子类，使代码依赖于抽象而非具体实现。

3. 抽象工厂模式 (Abstract Factory)

• 核心解决思路：提供一个接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类。
• 典型应用场景：跨平台UI组件库（创建Windows/Mac风格的按钮、文本框等）、数据库访问抽象层。
• 核心痛点：需要创建一整套相互关联的产品，且需要支持不同系列的产品。
• 简介：通过工厂的工厂来创建一系列相关对象，确保这些对象能够协同工作。

4. 建造者模式 (Builder)

• 核心解决思路：将一个复杂对象的构建与其表示分离，使得同样的构建过程可以创建不同的表示。
• 典型应用场景：创建复杂的SQL查询、定制化的邮件对象、生成器模式创建HTML文档。
• 核心痛点：构造函数参数过多且部分参数可选时，构造逻辑复杂且难以阅读。
• 简介：通过链式调用一步步设置属性，最后统一构建对象，提高可读性和灵活性。

5. 原型模式 (Prototype)

• 核心解决思路：通过复制现有实例来创建新实例，而不是通过新建类。
• 典型应用场景：游戏中的敌人复制、成本高昂的资源初始化、需要保存对象状态进行回滚的场景。
• 核心痛点：直接创建对象的成本较高，或者需要避免与类层次结构的耦合。
• 简介：实现Cloneable接口，通过clone方法复制对象，避免重复初始化过程。

结构型模式 (7种)

6. 适配器模式 (Adapter)

• 核心解决思路：将一个类的接口转换成客户端期望的另一个接口。
• 典型应用场景：整合不兼容的第三方库、旧系统接口改造、设备驱动兼容。
• 核心痛点：现有类的接口与客户期望的接口不匹配，无法直接使用。
• 简介：作为两个不兼容接口之间的桥梁，使它们能够一起工作。

7. 装饰器模式 (Decorator)

• 核心解决思路：动态地给一个对象添加一些额外的职责，而不改变其结构。
• 典型应用场景：Java I/O流处理、Web中间件链、咖啡加料计算系统。
• 核心痛点：需要动态、透明地给对象添加功能，使用继承会导致子类爆炸。
• 简介：通过包装原有对象，在不修改原类的情况下扩展功能。

8. 代理模式 (Proxy)

• 核心解决思路：为其他对象提供一种代理以控制对这个对象的访问。
• 典型应用场景：远程代理、虚拟代理（延迟加载）、保护代理（权限控制）、Spring AOP。
• 核心痛点：直接访问对象可能带来性能、安全或复杂性方面的问题。
• 简介：通过代理对象间接访问目标对象，可以在访问前后添加额外操作。

9. 外观模式 (Facade)

• 核心解决思路：提供一个统一的接口，用来访问子系统中的一群接口。
• 典型应用场景：框架API封装、复杂系统简化接口、家庭影院一键启动系统。
• 核心痛点：子系统过于复杂，客户端需要与多个子系统交互，耦合度高。
• 简介：定义了一个高层接口，让子系统更容易使用，降低了客户端与子系统的耦合度。

10. 桥接模式 (Bridge)

• 核心解决思路：将抽象部分与它的实现部分分离，使它们都可以独立地变化。
• 典型应用场景：跨平台应用程序、不同数据库驱动、形状与颜色的组合。
• 核心痛点：多个维度的变化会导致类数量急剧增加（M×N问题）。
• 简介：使用组合代替继承，将抽象和实现解耦，使它们可以独立扩展。

11. 组合模式 (Composite)

• 核心解决思路：将对象组合成树形结构以表示"部分-整体"的层次结构。
• 典型应用场景：文件系统表示、菜单组件、组织架构树、GUI容器组件。
• 核心痛点：需要统一处理单个对象和对象组合，避免区分对待带来的复杂性。
• 简介：让客户端可以一致地处理单个对象和对象组合，简化客户端代码。

12. 享元模式 (Flyweight)

• 核心解决思路：运用共享技术有效地支持大量细粒度的对象。
• 典型应用场景：文本编辑器中的字符对象、游戏中的粒子系统、数据库连接池。
• 核心痛点：大量相似对象消耗大量内存，需要优化资源使用。
• 简介：将对象的内部状态（不变部分）与外部状态（可变部分）分离，共享内部状态。

行为型模式 (11种)

13. 策略模式 (Strategy)

• 核心解决思路：定义一系列的算法，把它们一个个封装起来，并且使它们可相互替换。
• 典型应用场景：支付方式选择、排序算法切换、导航路线计算。
• 核心痛点：算法直接硬编码在类中，难以扩展和修改，违反开闭原则。
• 简介：将算法封装成独立策略类，使得算法可以独立于客户端变化。

14. 模板方法模式 (Template Method)

• 核心解决思路：定义一个操作中的算法骨架，而将一些步骤延迟到子类中。
• 典型应用场景：框架中的钩子方法、数据库访问模板、饮料制作过程。
• 核心痛点：多个类有相同算法框架但某些步骤实现不同，导致代码重复。
• 简介：在父类中定义算法骨架，子类可以重定义某些特定步骤而不改变算法结构。

15. 观察者模式 (Observer)

• 核心解决思路：定义对象间的一种一对多的依赖关系，当一个对象改变状态时，所有依赖者都会收到通知。
• 典型应用场景：事件处理系统、消息订阅、MVC模式中的模型-视图关系。
• 核心痛点：对象状态变化需要通知其他对象，但又不希望紧密耦合。
• 简介：主题维护观察者列表，状态变化时自动通知所有观察者。

16. 迭代器模式 (Iterator)

• 核心解决思路：提供一种方法顺序访问一个聚合对象中各个元素，而又不暴露该对象的内部表示。
• 典型应用场景：集合类遍历、数据库查询结果遍历、文件目录遍历。
• 核心痛点：需要以不同方式遍历聚合对象，但又不想暴露其内部结构。
• 简介：将遍历逻辑从聚合对象中分离出来，使得可以定义多种遍历方式。

17. 责任链模式 (Chain of Responsibility)

• 核心解决思路：让多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。
• 典型应用场景：审批流程、异常处理、过滤器链、Web请求处理。
• 核心痛点：请求发送者与多个可能的处理者之间存在强耦合，难以动态调整处理流程。
• 简介：将处理对象连成一条链，请求沿链传递直到有对象处理它。

18. 命令模式 (Command)

• 核心解决思路：将一个请求封装为一个对象，从而使你可以用不同的请求对客户进行参数化。
• 典型应用场景：GUI按钮操作、任务队列、事务处理、可撤销操作。
• 核心痛点：需要将请求发送者与接收者解耦，支持请求的排队、记录、撤销等操作。
• 简介：将请求封装成命令对象，可以参数化其他对象，支持请求的排队、记录和撤销。

19. 备忘录模式 (Memento)

• 核心解决思路：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。
• 典型应用场景：游戏存档、文本编辑器撤销、数据库事务回滚。
• 核心痛点：需要保存对象状态以便后续恢复，但又不想暴露对象内部细节。
• 简介：通过备忘录对象保存原始对象状态，需要时可以恢复到此状态。

20. 状态模式 (State)

• 核心解决思路：允许对象在内部状态改变时改变它的行为，对象看起来好像修改了它的类。
• 典型应用场景：工作流引擎、游戏角色状态、TCP连接状态。
• 核心痛点：对象行为依赖于它的状态，大量条件语句导致代码难以维护。
• 简介：将不同状态的行为封装到不同的状态类中，使状态转换更加清晰。

21. 访问者模式 (Visitor)

• 核心解决思路：表示一个作用于某对象结构中的各元素的操作，使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。
• 典型应用场景：编译器语法树分析、文档结构导出、复杂对象结构操作。
• 核心痛点：需要在复杂对象结构中添加新操作，但不想修改各个元素类。
• 简介：将操作与对象结构分离，通过访问者对象实现对结构中各元素的操作。

22. 中介者模式 (Mediator)

• 核心解决思路：用一个中介对象来封装一系列的对象交互，使各对象不需要显式地相互引用。
• 典型应用场景：聊天室系统、机场控制系统、GUI组件交互。
• 核心痛点：对象间存在复杂的网状引用关系，导致系统高度耦合难以维护。
• 简介：通过中介者集中管理对象间的通信，将网状结构变为星形结构。

23. 解释器模式 (Interpreter)

• 核心解决思路：给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。
• 典型应用场景：正则表达式、SQL解析、数学公式计算、业务规则引擎。
• 核心痛点：需要解释执行特定语法或表达式，但语法规则可能频繁变化。
• 简介：定义语法的类层次结构，通过解释器模式解释执行语法规则。

常用模式组合 (6种经典组合)

1. 工厂方法 + 单例模式

• 核心解决思路：集中管理对象生命周期，确保特定对象的唯一性。
• 典型应用场景：IoC容器（如Spring框架）、工具类管理器、配置信息访问点。
• 核心痛点：需要统一控制某类对象的创建和访问，避免重复实例化。
• 简介：工厂负责创建对象，并确保返回的是单例实例，隐藏创建逻辑的同时保证全局唯一性。

2. 观察者 + 中介者模式

• 核心解决思路：实现解耦的、可扩展的事件通信机制。
• 典型应用场景：消息中间件系统、前端状态管理（Redux/Vuex）、复杂事件处理系统。
• 核心痛点：多个组件间需要通信但直接引用会导致网状耦合，难以维护和扩展。
• 简介：观察者订阅事件，中介者协调所有通信，实现发布者和订阅者的完全解耦。

3. 策略 + 装饰器模式

• 核心解决思路：动态组合算法核心与功能增强，实现高度灵活的行为定制。
• 典型应用场景：支付处理流水线、数据处理管道、游戏技能系统。
• 核心痛点：需要灵活切换核心算法并能动态添加辅助功能，避免类爆炸问题。
• 简介：策略模式定义可互换的核心算法，装饰器模式动态添加横切关注点功能。

4. 建造者 + 原型模式

• 核心解决思路：高效、灵活地创建复杂配置对象。
• 典型应用场景：HTTP客户端配置、游戏实体生成、文档构建系统。
• 核心痛点：创建复杂对象成本高，需要基于现有配置进行微调而不是从头构建。
• 简介：使用原型作为配置模板，建造者基于模板进行定制化构建，兼顾性能和灵活性。

5. 适配器 + 外观模式

• 核心解决思路：集成并简化复杂子系统或第三方服务。
• 典型应用场景：多平台服务整合、遗留系统现代化改造、统一API网关。
• 核心痛点：需要整合多个不兼容的接口，并为客户端提供简单统一的访问方式。
• 简介：适配器解决接口不兼容问题，外观提供简化的高级接口，分层解决复杂度。

6. 命令 + 备忘录模式

• 核心解决思路：实现可撤销、可重做的操作序列管理。
• 典型应用场景：文本编辑器、图形绘图软件、事务性操作管理系统。
• 核心痛点：需要支持操作撤销、重做功能，并能保存操作历史记录。
• 简介：命令模式封装操作，备忘录模式保存状态，两者结合实现完整的撤销/重做机制。

总结

这份清单涵盖了23种经典设计模式及其6种常用组合，为软件设计提供了全面的解决方案工具箱。在实际开发中，往往需要根据具体场景选择并组合使用多种模式，而不是局限于单一模式。理解每种模式的核心解决思路和适用场景，能够帮助开发者在面对复杂软件设计问题时做出更加合理的选择。

值得注意的是，设计模式不是银弹，过度使用或错误使用模式反而会增加系统复杂性。正确的做法是深入理解问题本质，然后选择最简单有效的解决方案，必要时才引入适当的设计模式。