设计模式
概括
设计模式是软件开发中，针对特定问题的、可复用的、经过验证的优雅解决方案。
它们不是具体的代码或算法，而是一种编程思想和代码组织方式。
为什么需要设计模式？
- 可复用性：将成熟的设计方案应用到不同项目中，避免重复造轮子。
- 可读性与可维护性：使用统一的"设计语言"，让团队成员能快速理解代码结构，降低维护成本。
- 可靠性：这些模式经过大量实践检验，使用它们可以构建更稳定、更健壮的系统。
- 提升沟通效率：当你说"这里用个单例模式"时，大家都能立刻明白你的意图。
设计模式的三大分类
🏗️ 创建型模式
核心思想：专注于"怎么优雅地创建对象"，让对象创建更灵活可控，将创建与使用解耦。
| 模式 | 目的 | 关键词 | 链接 |
|---|---|---|---|
| 工厂模式 | 定义创建对象的接口，让子类决定实例化哪一个类。 | 封装创建、解耦、产品族 | ✅ |
| 单例模式 | 保证一个类仅有一个实例，并提供一个全局访问点。 | 唯一实例、全局访问 | ✅ |
| 原型模式 | 通过复制现有实例来创建新的实例，而非通过 new。 | 克隆、复制、高效创建 | 🚧 |
| 建造者模式 | 将一个复杂对象的构建与其表示分离，使得同样的构建过程可以创建不同的表示。 | 链式调用、分步构建、复杂对象 | 🚧 |
🧱 结构型模式
核心思想：专注于"如何组合类和对象"，通过巧妙的组合形成更大、更灵活的结构。
| 模式 | 目的 | 关键词 | 链接 |
|---|---|---|---|
| 适配器模式 | 将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。 | 接口转换、兼容、包装器 | ✅ |
| 装饰器模式 | 动态地给一个对象添加一些额外的职责。就增加功能来说，装饰器模式相比生成子类更为灵活。 | 动态增强、包装、非继承 | ✅ |
| 代理模式 | 为其他对象提供一种代理以控制对这个对象的访问。 | 访问控制、代理、中间人 | ✅ |
| 外观模式 | 为子系统中的一组接口提供一个一致的界面，定义一个高层接口，这个接口使得这一子系统更加容易使用。 | 简化接口、封装子系统 | ✅ |
| 桥接模式 | 将抽象部分与它的实现部分分离，使它们都可以独立地变化。 | 抽象与实现分离、多维变化 | 🚧 |
| 组合模式 | 将对象组合成树形结构以表示"部分-整体"的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。 | 树形结构、部分-整体、统一操作 | 🚧 |
| 享元模式 | 运用共享技术来有效地支持大量细粒度的对象，避免大量相似对象的开销。 | 共享、池化、减少内存占用 | 🚧 |
🚀 行为型模式
核心思想：专注于"对象之间如何协作和通信"，定义对象间的职责分配和交互方式。
| 模式 | 目的 | 关键词 | 链接 |
|---|---|---|---|
| 策略模式 | 定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。 | 算法封装、可替换、消灭 if-else | ✅ |
| 模板方法模式 | 定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。 | 算法骨架、子类实现细节、代码复用 | 🚧 |
| 观察者模式 | 定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。 | 一对多依赖、发布-通知、状态变化 | ✅ |
| 发布订阅模式 | 一种消息范式，发送者（发布者）不会将消息直接发送给特定的接收者（订阅者）。 | 解耦、消息队列、事件总线 | ✅ |
| 迭代器模式 | 提供一种方法顺序访问一个聚合对象中各个元素, 而又不需暴露该对象的内部表示。 | 顺序访问、统一遍历接口 | 🚧 |
| 职责链模式 | 使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。 | 请求传递、链式处理、多级审批 | 🚧 |
| 命令模式 | 将一个请求封装成一个对象，从而使你可用不同的请求对客户进行参数化。 | 请求封装、撤销/重做、队列 | 🚧 |
| 备忘录模式 | 在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。 | 状态保存、快照、撤销 | 🚧 |
| 状态模式 | 允许一个对象在其内部状态改变时改变它的行为。 | 状态驱动行为、多状态对象 | 🚧 |
| 访问者模式 | 表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。 | 操作分离、稳定数据结构、易变操作 | 🚧 |
| 中介者模式 | 用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散。 | 中心协调、解耦多对多关系 | 🚧 |
| 解释器模式 | 给定一种语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。 | 文法解析、DSL、较少使用 | 🚧 |
如何选择设计模式？
| 场景/问题 | 推荐模式 | 典型应用 |
|---|---|---|
| 需要根据不同条件创建不同对象，但不想让调用者与具体类耦合 | 工厂模式 | 创建不同类型的数据库连接、UI 组件 |
| 需要保证全局只有一个实例（如配置、日志、连接池） | 单例模式 | 全局配置管理器、日志记录器 |
| 想在不修改原有对象的情况下，动态地增加或修改其功能 | 装饰器模式 | 给文本添加格式、给图片添加滤镜 |
| 想要控制对某个对象的访问（如延迟加载、权限控制） | 代理模式 | 图片懒加载、API 权限控制 |
| 有两个不兼容的接口需要协同工作 | 适配器模式 | 整合第三方库、旧系统接口适配 |
| 系统非常复杂，需要提供一个简化的统一入口 | 外观模式 | 封装复杂的底层库、提供简化 API |
有一组算法可以互相替换，并希望避免使用大量的 if-else | 策略模式 | 不同的排序算法、支付方式选择 |
| 一个对象状态改变时，需要自动通知其他多个对象 | 观察者模式 | 数据绑定、事件监听系统 |
| 想将请求的发送者和接收者完全解耦 | 发布订阅模式 | 消息队列、事件总线 |
| 有一个固定的处理流程，但其中某些步骤需要由子类实现 | 模板方法模式 | 数据处理流程、测试框架 |
| 需要快速复制大量相似对象 | 原型模式 | 游戏角色克隆、文档模板 |
| 构建复杂对象时，希望通过链式调用分步设置属性 | 建造者模式 | 构建复杂配置对象、SQL 查询构建器 |
| 需要遍历集合，但不想暴露集合内部结构 | 迭代器模式 | 自定义集合遍历、树形结构遍历 |
| 请求需要经过多个处理者，每个处理者负责一部分逻辑 | 职责链模式 | 多级审批流程、中间件系统 |
| 需要将操作封装成对象，支持撤销/重做 | 命令模式 | 编辑器的撤销/重做、事务管理 |
⚠️ 使用设计模式的注意事项
- 不要过度设计：简单问题不需要复杂模式，不要为了用模式而用模式。
- 理解场景再使用：每个模式都有其适用场景，不是所有项目都需要所有模式。
- 团队共识很重要：确保团队成员理解你使用的模式，否则会增加维护难度。
- 性能 vs 可维护性：有些模式会引入额外的抽象层，需要权衡性能和代码可维护性。
- 从简单开始：先掌握常用的模式（单例、工厂、策略、观察者），再逐步学习其他模式。
图例说明
- ✅ 已实现：该模式已有详细文档和示例。
- 🚧 待实现：该模式计划补充。
📚 推荐学习路径
初学者（先掌握这 5 个）：
- 单例模式 → 工厂模式 → 策略模式 → 观察者模式 → 装饰器模式
进阶（扩展到 10 个）：
- 在上述基础上加入：代理模式 → 适配器模式 → 外观模式 → 模板方法 → 发布订阅
高级（完整掌握）：
- 根据实际需求补充学习其他模式