职责链模式与
命令模式
Sunny Liu
weiliu_china@
m
内 容
行为模式
职责链模式
命令模式
行为模式
行为模式（Behavioral Pattern）是对在不同的对象之间划分责任和算法
的抽象化。行为模式不仅仅是关于类和对象的，而且是关于它们之间
的相互作用的。
行为模式分为类的行为模式和对象的行为模式两种：
类的行为模式：类的行为模式使用继承关系在几个类之间分配行为。
对象的行为模式：对象的行为模式则使用对象的聚合来分配行为。
行为模式（续）
行为模式：
职责链模式（Chain of Responsibility）
命令模式（Command）
迭代器模式（Iterator）
中介者模式（Mediator）
备忘录模式（Memento）
观察者模式（Observer）
状态模式（State）
策略模式（Strategy）
模板方法模式（Template Method）
访问者模式（Visitor）
职责链模式
模式动机
在职责链模式里，很多对象由每一个对象对其下家的引用而连接起来
形成一条链。请求在这个链上传递，直到链上的某一个对象决定处理
此请求。发出这个请求的客户端并不知道链上的哪一个对象最终处理
这个请求，这使得系统可以在不影响客户端的情况下动态地重新组织
链和分配责任。
职责链模式（续）
模式定义
职责链模式(Chain of Responsibility Pattern)：避免请求发送者与接收者
耦合在一起，让多个对象都有可能接收请求，将这些对象连接成一条
链，并且沿着这条链传递请求，直到有对象处理它为止。职责链模式
是一种对象的行为模式。
职责链模式（续）
模式结构
职责链模式（续）
参与者
Handler：抽象传递者
ConcreteHandler：具体传递者
Client：客户类
职责链模式（续）
模式解释
一个定义处理请求(handleRequest)的接口，如果有多个请求，比如帮助
请求、打印请求或格式化请求，我们怎么解决呢？
职责链模式（续）
实例分析
实例：下达作战命令
职责链模式（续）
实例分析
实例：下达作战命令（代码实现）
职责链模式（续）
模式优缺点
降低耦合度
增强了给对象指派职责的灵活性
不保证被接受
扩展性差
职责链模式（续）
模式使用
在以下条件下可以使用职责链模式：
有多个对象可以处理同一个请求，哪个对象处理该请求由运行时刻自
动确定。
在不明确指定接收者的情况下，向多个对象中的一个提交一个请求。
可动态指定一组对象处理请求。
职责链模式（续）
模式应用
Java中的异常处理类似一种职责链模式
Java事件模型(JDK 或更早)
纸牌游戏
职责链模式可以应用于图形用户界面中
职责链模式（续）
模式深入
纯的与不纯的职责链模式
一个纯的职责链模式要求一个具体的处理者对象只能在两个行为中选择一个：
一个是承担责任，二是把责任推给下家。不允许出现某一个具体处理者对象在
承担了一部分责任后又把责任向下传的情况。在一个纯的职责链模式里面，一
个请求必须被某一个处理者对象所接收；在一个不纯的职责链模式里面，一个
请求可以最终不被任何接收端对象所接收。纯的职责链模式的例子是不容易找
到的，一般看到的例子均是不纯的职责链模式的实现。
练 习
职责链模式中有哪些参与者，简述其职责。
用职责链写一个专家系统，它一个接一个的尝试不同的解决方法，直
到找到某个解决问题的方法为止。要求专家系统可以动态的添加解
决方法。测试方法用字符串匹配，但是当匹配以后专家系统必须返
回适当类型的ProblemSolver对象。考虑下，这里还会用到什么其它
的模式？
命令模式
模式动机
在软件开发过程中，有时我们需要向某些对象发送请求，但是不知道 “被请求
的操作” 或 “请求的接受者”的任何信息。在面向过程的程序设计语言中，这
类通信是通过回调函数来完成的：在某个地方登记这个函数，然后在后面调用
它。在面向对象程序中，command(命令)与回调函数等价，它封装了回调函数。
命令模式可以对发送者(sender)和接收者(receiver)完全解耦(decoupling)。（“发
送者”是请求操作的对象，“接收者”是接收请求并执行某操作的对象。有了
“解耦”，发送者对接收者的接口一无所知。）在这里，“请求”(request)这
个术语指的是要被执行的命令。命令模式还让我们可以对“何时”以及“如何
”完成请求进行改变。因此，命令模式为我们提供了灵活性和可扩展性。
命令模式（续）
模式定义
命令模式(Command Pattern)：将一个请求封装为一个对象，从而使我们
可用不同的请求对客户进行参数化；对请求排队或者记录请求日志，以
及支持可撤销的操作。命令模式是一种对象行为型模式，其别名为动作
(Action)、事务(Transaction)。
命令模式（续）
模式结构
命令模式（续）
参与者
Command：抽象命令类
ConcreteCommand：具体命令类
Client：客户应用程序
Invoker：调用者
Receiver：接收者
命令模式（续）
模式解释
命令模式（续）
实例分析
实例一：电视机遥控器
命令模式（续）
实例分析
实例一：电视机遥控器（代码实现）
命令模式（续）
实例分析
实例二：简单计算器
命令模式（续）
实例分析
实例二：简单计算器 （代码实现）
命令模式（续）
模式优缺点
命令允许请求的一方和接收请求的一方能够独立演化，从而有以下的优点：
命令模式使新的命令很容易地被加入到系统里。
允许接收请求的一方决定是否要否决请求。
能较容易地设计一个命令队列。
可以容易地实现对请求的Undo和Redo。
在需要的情况下，可以较容易地将命令记入日志。
命令模式把请求一个操作的对象与知道怎么执行一个操作的对象分割开。
命令类与其它任何别的类一样，可以修改和推广。
可以把命令对象聚合在一起，合成为合成命令。比如宏命令便是合成命令的例
子。合成命令是组合模式的应用。
由于加进新的具体命令类不影响其它的类，因此增加新的具体命令类很容易。
命令模式（续）
模式优缺点
命令模式的主要缺点如下：
使用命令模式会导致某些系统有过多的具体命令类。某些系统可能需要
几十个，几百个甚至几千个具体命令类，这会使命令模式在这样的系统
里变得不实际。
命令模式（续）
模式使用
在下面的情况下应当考虑使用命令模式：
使用命令模式作为“CallBack”在面向对象系统中的替代。
需要在不同的时间指定请求、将请求排队。
系统需要支持命令的撤消(undo)。
如果一个系统要将系统中所有的数据更新到日志里，以便在系统崩溃时，可以
根据日志里读回所有的数据更新命令，重新调用execute()方法一条一条执行这
些命令，从而恢复系统在崩溃前所做的数据更新。
一个系统需要支持交易(Transaction)。
命令模式（续）
模式应用
Java语言使用了命令模式实现中的事件委派处理模型
许多软件的宏命令功能是命令模式的实际应用
练 习
命令模式中有哪些参与者，简述其职责。
房间中的开关就是命令模式的一个实现，现用命令模式来模拟开关的
功能，可控制对象包括电灯和电风扇，并绘制相应的类图。
Thank You !
