考试分值：设计模式固定4分
一、行为型模式概述
行为型模式关注对象之间的通信和职责分配，描述对象之间怎样协作完成任务。
| 模式 | 英文名 | 意图关键词 |
|---|---|---|
| 责任链 | Chain of Responsibility | 链式传递请求 |
| 命令 | Command | 请求封装为对象 |
| 解释器 | Interpreter | 定义文法，解释句子 |
| 迭代器 | Iterator | 顺序访问聚合对象元素 |
| 中介者 | Mediator | 封装对象交互，松散耦合 |
| 备忘录 | Memento | 捕获并恢复对象内部状态 |
| 观察者 | Observer | 一对多依赖，状态变化通知 |
| 策略 | Strategy | 封装算法，互相替换 |
| 状态 | State | 状态改变时改变行为 |
| 模板方法 | Template Method | 算法骨架，延迟步骤到子类 |
| 访问者 | Visitor | 不改变类定义新操作 |
二、各模式详解
2.1 责任链模式（Chain of Responsibility）
意图：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。
核心要点：
- 将多个处理对象连成一条链
- 请求沿着链传递
- 直到有一个对象处理该请求为止
- 解耦请求的发送者和接收者
适用场景：
- 有多个对象可以处理一个请求，但哪个对象处理在运行时自动确定
- 在不明确指定接收者的情况下，向多个对象中的一个提交请求
2.2 命令模式（Command）
意图：将一个请求封装为一个对象，从而使得可以用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。
核心要点：
- 将请求封装为对象
- 可以对请求进行参数化、排队、记录日志
- 支持可撤销的操作
- 将请求发送者和接收者解耦
适用场景：
- 需要将请求调用者和接收者解耦
- 需要支持撤销/重做操作
- 需要对请求进行排队或日志记录
2.3 解释器模式（Interpreter）
意图：给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。
核心要点：
- 定义语言的文法表示
- 定义一个解释器来解释句子
- 适用于简单的语法解析
适用场景：
- 该文法简单，对于复杂的文法，文法的类层次变得庞大而无法管理
- 效率不是一个关键问题
2.4 迭代器模式（Iterator）
意图：提供一种方法顺序访问一个聚合对象中的各个元素，且不需要暴露该对象的内部表示。
核心要点：
- 顺序访问聚合对象中的各个元素
- 不需要暴露该对象的内部表示
- 提供统一的遍历接口
适用场景：
- 需要遍历聚合对象中的元素
- 不希望暴露聚合对象的内部结构
2.5 中介者模式（Mediator）
意图：用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
核心要点：
- 用中介对象封装对象交互
- 各对象不需要显式相互引用
- 使耦合松散
- 可以独立改变对象之间的交互
适用场景：
- 一组对象以定义良好但复杂的方式进行通信
- 想要定制一个分布在多个类中的行为，但又不想生成太多的子类
2.6 备忘录模式（Memento）
意图：在不破坏封装性的前提下捕获一个对象的内部状态，并在对象之外保存这个状态。这样以后就可以将对象恢复到原先保存的状态。
核心要点：
- 捕获对象的内部状态
- 不破坏封装性
- 在对象之外保存状态
- 可以恢复到原先保存的状态
适用场景：
- 需要保存/恢复对象的状态
- 保存状态的操作不能破坏对象的封装性
2.7 观察者模式（Observer）
意图：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。
核心要点：
- 一对多的依赖关系
- 主题（被观察者）状态改变时，通知所有观察者
- 观察者自动更新
适用场景：
- 当一个抽象模型有两个方面，其中一个方面依赖于另一方面
- 当对一个对象的改变需要同时改变其他对象，而不知道具体有多少对象有待改变
- 当一个对象必须通知其他对象，而它又不能假定其他对象是谁
2.8 策略模式（Strategy）
意图：定义一系列的算法，把它们一个个封装起来，并且使它们可以互相替换。此模式使得算法可以独立于使用它们的客户而变化。
核心要点：
- 定义一系列算法
- 将算法封装起来
- 算法之间可以互相替换
- 算法独立于使用它的客户而变化
适用场景：
- 多个类只在行为上有差异
- 需要在运行时动态选择算法
- 需要避免使用多重条件判断语句
2.9 状态模式（State）
意图：允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。
核心要点：
- 对象的内部状态改变时改变行为
- 对象看起来似乎修改了它的类
- 将状态相关的行为封装到独立的状态类中
适用场景：
- 一个对象的行为取决于它的状态，并且它必须在运行时根据状态改变行为
- 一个操作中含有庞大的多分支条件语句
2.10 模板方法模式（Template Method）
意图：定义一个操作中的算法骨架，而将一些步骤延迟到子类中。Template Method使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
核心要点：
- 定义算法的骨架
- 将一些步骤延迟到子类
- 子类可以不改变算法结构，重定义某些特定步骤
- 典型的"控制反转"应用
适用场景：
- 一次性实现一个算法的不变部分，并将可变的行为留给子类
- 各子类中公共的行为应被提取出来集中到一个公共父类中
2.11 访问者模式（Visitor）
意图：表示一个作用于某对象结构中的各元素的操作。它允许在不改变各元素的类的前提下定义作用于这些元素的新操作。
核心要点：
- 在不改变各元素的类的前提下定义新操作
- Visitor（访问者）为该对象结构中 ConcreteElement 的每一个类声明一个 Visit 操作
- 该操作的名字和特征标识了发送 Visit 请求给该访问者的那个类
- 使得访问者可以确定正被访问元素的具体的类
- 访问者可以通过该元素的特定接口直接访问它
适用场景：
- 一个对象结构包含很多类对象，它们有不同的接口
- 需要对一个对象结构中的对象进行很多不同的且不相关的操作
- 需要频繁地对对象结构中的对象添加新操作
三、行为型模式对比总结
| 模式 | 核心思想 | 关键词 |
|---|---|---|
| 责任链 | 链式传递请求 | 链、传递、解耦 |
| 命令 | 请求封装为对象 | 封装、撤销、排队 |
| 解释器 | 定义文法解释句子 | 文法、解释 |
| 迭代器 | 顺序访问不暴露内部 | 遍历、封装 |
| 中介者 | 封装交互松散耦合 | 中介、解耦 |
| 备忘录 | 捕获并恢复状态 | 保存、恢复、撤销 |
| 观察者 | 一对多依赖通知 | 通知、更新、发布-订阅 |
| 策略 | 封装算法互相替换 | 算法、替换、动态 |
| 状态 | 状态改变改变行为 | 状态、行为 |
| 模板方法 | 算法骨架延迟步骤 | 骨架、延迟、重定义 |
| 访问者 | 不改类定义新操作 | 新操作、不改类 |
四、常考模式辨析
策略模式 vs 状态模式
| 对比项 | 策略模式 | 状态模式 |
|---|---|---|
| 目的 | 选择算法 | 管理状态 |
| 切换条件 | 由客户端决定 | 由对象内部状态决定 |
| 变化原因 | 外部条件 | 内部状态 |
观察者模式 vs 中介者模式
| 对比项 | 观察者模式 | 中介者模式 |
|---|---|---|
| 目的 | 一对多通知 | 多对多协调 |
| 方向 | 单向通知 | 双向交互 |
| 关系 | 主题通知观察者 | 中介协调所有对象 |
模板方法模式 vs 策略模式
| 对比项 | 模板方法模式 | 策略模式 |
|---|---|---|
| 实现方式 | 继承 | 组合 |
| 变化粒度 | 算法的某些步骤 | 整个算法 |
| 变化时机 | 编译时确定 | 运行时切换 |
五、考试重点
- 必背各模式的意图描述（考试常考模式识别）
- 观察者模式的一对多依赖关系
- 策略模式 vs 状态模式的区别
- 模板方法模式的继承和延迟
- 命令模式的请求封装和撤销支持
- 访问者模式的核心：不改类定义新操作
评论