设计模式是解决软件设计中重复问题的可复用方案，按照其核心意图可分为三大类：创建型模式、结构型模式、行为型模式。此外，还有针对特定场景的“并发型模式”和“架构型模式”，但前三类是业界公认的基础分类，覆盖了绝大多数日常设计需求。
一、核心分类：三大基础类型
三大类模式的本质区别在于解决的问题维度不同：
- 创建型模式 ：关注“对象如何创建”，解耦对象创建与使用；
- 结构型模式 ：关注“对象/类如何组合”，优化类或对象的结构关系；
- 行为型模式 ：关注“对象如何交互”，定义对象间的通信与职责分配。
1. 创建型模式（Creational Patterns）
核心目标是控制对象的创建过程，避免硬编码创建逻辑导致的耦合，提高代码灵活性和可复用性。常见场景包括“单例对象创建”“复杂对象分步构建”“根据条件动态创建不同对象”等。
| 模式名称 | 核心意图 | 典型应用场景 |
|---|---|---|
| 单例模式（Singleton） | 确保一个类仅有一个实例，并提供全局访问点。 | 全局配置类、日志工具、线程池（避免重复创建资源消耗）。 |
| 工厂方法模式（Factory Method） | 定义创建对象的接口，让子类决定实例化哪个类，将创建逻辑延迟到子类。 | 框架扩展（如日志框架支持“文件日志”“控制台日志”，子类实现具体创建）。 |
| 抽象工厂模式（Abstract Factory） | 提供一个接口，用于创建一系列相关/依赖对象，无需指定具体类。 | 跨产品族创建（如“Windows风格按钮+Windows风格文本框”“Mac风格按钮+Mac风格文本框”）。 |
| 建造者模式（Builder） | 将复杂对象的构建与表示分离，同一构建过程可生成不同表示。 | 复杂对象创建（如“订单对象”需包含商品列表、收货地址、支付方式，分步构建）。 |
| 原型模式（Prototype） | 通过复制现有对象（原型）来创建新对象，避免重复初始化的开销。 | 对象初始化成本高的场景（如从数据库加载配置后，复制原型生成新对象）。 |
2. 结构型模式（Structural Patterns）
核心目标是优化类或对象的组合方式，通过灵活的结构设计满足功能扩展需求，同时避免类爆炸或耦合过重。常见场景包括“类的功能扩展”“对象的灵活组合”“接口适配”等。
| 模式名称 | 核心意图 | 典型应用场景 |
|---|---|---|
| 适配器模式（Adapter） | 将一个类的接口转换成客户端期望的另一个接口，解决接口不兼容问题。 | 旧系统集成（如老接口返回List，新系统需要Set，适配器转换格式）。 |
| 装饰器模式（Decorator） | 动态给对象添加额外职责，不改变原类结构，比继承更灵活。 | 功能动态扩展（如“基础咖啡”→“加奶咖啡”→“加奶加糖咖啡”，每个装饰器添加一个功能）。 |
| 代理模式（Proxy） | 为其他对象提供一种代理，控制对原对象的访问（如权限控制、延迟加载）。 | 远程服务调用（RPC代理）、懒加载（如大图片加载前先显示占位图）、权限校验。 |
| 组合模式（Composite） | 将对象组合成树形结构，使单个对象和组合对象的使用方式一致。 | 树形结构操作（如“文件夹-文件”结构，删除文件夹=删除所有子文件，统一调用delete）。 |
| 外观模式（Facade） | 为子系统提供一个统一的高层接口，简化子系统的使用。 | 复杂框架封装（如“支付子系统”包含订单校验、支付调用、回调处理，外观类提供pay统一接口）。 |
| 享元模式（Flyweight） | 复用细粒度对象，减少内存消耗（通过共享相同状态的对象）。 | 大量相似对象场景（如游戏中的“士兵”，共享“模型、材质”等状态，仅差异化“位置、血量”）。 |
| 桥接模式（Bridge） | 将抽象部分与实现部分分离，使两者可独立变化（解耦继承，用组合替代）。 | 多维度变化场景（如“操作系统（Windows/Mac）”与“浏览器（Chrome/Firefox）”，桥接类关联两者，独立扩展）。 |
3. 行为型模式（Behavioral Patterns）
核心目标是定义对象间的交互规则与职责分配，解决“对象如何通信”“行为如何复用”“职责如何拆分”等问题，提高代码的可维护性和可扩展性。
| 模式名称 | 核心意图 | 典型应用场景 |
|---|---|---|
| 策略模式（Strategy） | 定义一系列算法，将每个算法封装起来，使它们可互相替换（解耦算法定义与使用）。 | 多种计算逻辑（如“支付方式”包含“微信支付”“支付宝支付”，客户端可切换策略）。 |
| 模板方法模式（Template Method） | 定义算法骨架，将步骤延迟到子类实现（固定流程，灵活步骤）。 | 固定流程的差异化实现（如“考试流程”：固定“发卷→答题→交卷”，子类实现“答题”步骤）。 |
| 观察者模式（Observer） | 定义对象间的一对多依赖，当一个对象变化时，所有依赖它的对象会自动更新。 | 事件通知（如“公众号-订阅者”，公众号更新后，所有订阅者收到推送）。 |
| 迭代器模式（Iterator） | 提供一种方法遍历聚合对象（如集合），无需暴露其内部结构。 | 集合遍历（如Java的Iterator接口，统一List、Set的遍历方式）。 |
| 责任链模式（Chain of Responsibility） | 将请求的处理者连成链，请求沿链传递，直到有处理者处理它（解耦请求与处理）。 | 多层校验（如“订单提交”：先校验库存→校验权限→校验支付，每个处理器处理后传递请求）。 |
| 命令模式（Command） | 将请求封装成对象，使请求的发送者与接收者解耦（支持撤销、队列化）。 | 操作记录与撤销（如“文本编辑器”的“复制”“粘贴”“撤销”，每个操作封装为命令对象）。 |
| 备忘录模式（Memento） | 在不破坏封装的前提下，保存对象的内部状态，以便后续恢复。 | 状态回滚（如“游戏存档”“文本编辑器的历史记录”）。 |
| 状态模式（State） | 将对象的状态封装成独立类，使对象在不同状态下表现出不同行为（状态驱动行为）。 | 状态依赖行为（如“订单状态”：待支付→已支付→已发货→已完成，每个状态对应不同操作）。 |
| 访问者模式（Visitor） | 定义一个作用于对象结构中各元素的操作，在不改变元素类的前提下扩展新操作。 | 复杂对象结构的多维度操作（如“文档解析”：同一文档结构，支持“统计字数”“提取关键词”等不同访问者操作）。 |
| 中介者模式（Mediator） | 用一个中介对象封装对象间的交互，减少对象间的直接耦合。 | 多组件通信（如“聊天软件”：用户A、B、C不直接通信，通过服务器（中介者）转发消息）。 |
| 解释器模式（Interpreter） | 定义语言的文法，并用解释器解释该语言的句子（较少用于日常开发）。 | 特定语法解析（如“表达式计算器”解析1+2*3，自定义规则引擎解析配置文件）。 |
二、扩展分类：特定场景模式
除三大基础类型外，还有两类针对特殊场景的模式，更多用于架构设计或并发编程：
1. 并发型模式（Concurrency Patterns）
解决多线程/多进程环境下的同步、通信、资源共享问题，确保线程安全和性能。
- 常见模式：生产者-消费者模式、线程池模式、Future模式（异步结果）、信号量模式、读写锁模式等。
- 应用场景：高并发系统（如电商秒杀、消息队列）、多线程任务处理。
2. 架构型模式（Architectural Patterns）
比基础设计模式更宏观，定义整个软件系统的架构结构，指导系统级别的设计。
- 常见模式：MVC模式（模型-视图-控制器）、MVP模式（模型-视图-Presenter）、MVVM模式（模型-视图-视图模型）、微服务模式、分层模式（表现层、业务层、数据层）等。
- 应用场景：系统架构设计（如Web应用用MVC，移动端用MVVM）。
三、设计模式学习建议
- 先理解“意图”，再记“实现” ：每个模式的核心是“解决什么问题”，而非固定代码模板（不同语言实现不同）。
- 避免过度设计 ：不要为了用模式而用模式，简单问题（如一个类仅创建一次）可直接手写，无需强行套用单例模式。
- 结合场景记忆 ：将模式与实际业务场景绑定（如“组合模式→文件夹结构”“观察者模式→消息通知”），更容易理解和复用。
通过掌握三大基础类型的核心逻辑，可应对绝大多数日常开发中的设计问题，而扩展模式则可在架构设计或并发场景中进一步提升系统的灵活性和性能。
本文使用 文章同步助手 同步
