一句话总结
在父类定义算法骨架，把可变步骤交给子类实现。
问题与场景
- 多个流程大致相同，但某些步骤不同。
- 希望复用通用流程，避免重复代码。
- 需要约束执行顺序，同时保留扩展点。
模式意图
定义算法的骨架，将某些步骤延迟到子类中实现，不改变算法结构即可扩展细节。
结构图
角色与职责
- 抽象类：定义模板方法和通用流程。
- 具体类：实现差异化步骤。
大约 3 分钟
一句话总结
把对象在不同状态下的行为封装到不同状态类中，让状态切换替代复杂的条件分支。
问题与场景
- 对象有多种状态，行为随状态变化，if/else 很快变成“状态泥潭”。
- 新增状态或规则时，修改面大且容易引入 bug。
- 希望状态转换更清晰、可测试、可扩展。
模式意图
允许对象在内部状态改变时改变其行为，看起来像是修改了对象的类。
结构图
角色与职责
大约 4 分钟
一句话总结
把可互换的算法封装成策略，让调用方在运行时灵活选择。
问题与场景
- 同一业务存在多种算法或规则（计费、风控、推荐等）。
- if/else 或 switch 分支不断增加，代码难维护。
- 需要按配置、用户类型或业务条件动态切换算法。
模式意图
定义一系列算法，并将其封装起来，使它们可以互相替换，算法的变化独立于使用它的客户端。
结构图
角色与职责
大约 3 分钟
一句话总结
当一个对象状态变化时，自动通知并更新所有依赖它的对象。
问题与场景
- 一个事件发生后，需要触发多个后续动作（通知、发券、积分、日志等）。
- 不希望发布者直接依赖各个订阅者，避免耦合过深。
- 订阅者可能增删变化，要求动态扩展。
模式意图
定义对象间一对多的依赖关系，当一个对象改变状态时，所有依赖于它的对象都会收到通知并自动更新。
结构图
角色与职责
大约 3 分钟
一句话总结
将操作从对象结构中抽离出来，让“新增操作”比“新增节点类型”更容易。
问题与场景
- 对象结构稳定，但需要频繁新增不同操作（统计、导出、校验）。
- 不希望每次新增操作都修改各个元素类。
- 需要对不同元素类型执行不同逻辑。
模式意图
表示一个作用于某对象结构中各元素的操作，使你可以在不改变元素类的前提下定义新操作。
结构图
角色与职责
大约 4 分钟
一句话总结
用一个“中介者”集中协调多个对象的交互，避免对象之间的网状依赖。
问题与场景
- 多个组件相互调用，关系变成“网状”，改一处影响多处。
- 业务流程有清晰的协作顺序，但各模块不该直接依赖对方。
- 需要把“协作规则”集中管理，方便调整与复用。
模式意图
用中介者对象封装一系列对象的交互，使各对象不需要显式地相互引用，从而降低耦合。
结构图
角色与职责
大约 4 分钟
一句话总结
在不暴露对象内部结构的前提下，保存并恢复对象的历史状态。
问题与场景
- 需要“撤销/回滚/恢复”能力，但不想让外部直接操作内部状态。
- 状态变化频繁，且希望能够按时间回溯。
- 希望保存快照，同时保持对象封装性。
模式意图
在不破坏封装的前提下捕获并保存对象内部状态，以便之后恢复到该状态。
结构图
角色与职责
- 发起者：需要保存/恢复状态的对象。
- 备忘录：状态快照，仅由 发起者 创建与读取。
- 管理者：保存快照并在需要时触发恢复。
大约 3 分钟
一句话总结
将集合的遍历逻辑封装在迭代器中，让客户端在不暴露内部结构的情况下顺序访问元素。
问题与场景
- 需要遍历不同的数据结构（数组、链表、树），但希望对外统一“遍历方式”。
- 不想暴露集合内部实现细节，避免外部直接操作底层数据。
- 需要多种遍历策略（顺序、倒序、过滤）并能独立演进。
模式意图
提供一种方法顺序访问聚合对象中的各个元素，而无需暴露其内部表示。
结构图
大约 4 分钟
一句话总结
把“请求”封装成命令对象，让调用者与执行者解耦，并支持队列、日志、撤销等扩展能力。
问题与场景
- 调用方需要发起操作，但不应直接依赖具体执行逻辑。
- 业务希望支持“批量执行、异步队列、操作记录、撤销/重试”。
- 处理流程可能由配置决定，执行者可能随时替换。
模式意图
将请求封装成对象，使你可以用不同的请求对客户端进行参数化，并支持对请求的排队、记录、撤销等操作。
结构图
大约 4 分钟
一句话总结
把一组处理器串成链，请求沿链传递，直到被某个处理器处理或到达链尾。
问题与场景
- 需要一套“流水线式”的处理流程，例如登录校验、限流、权限、业务校验、风控。
- 处理规则经常增删改，且顺序可能变化。
- 希望调用方不关心具体由谁处理，只管把请求丢进来。
模式意图
解耦请求发送者与多个处理者，使多个对象都有机会处理请求，并且可以在运行时灵活组合处理顺序。
结构图
大约 5 分钟