介绍
命令(Command)模式:将一个请求封装成一个对象,从而使你可用不同的请求对客户进行参数化,对请求排队或记录请求日志,以及支持可撤销的操作。
在软件开发系统中,常常出现“方法的请求者”与“方法的实现者”之间存在紧密的耦合关系。这不利于软件功能的扩展与维护。例如,想对行为进行“撤销、重做、记录”等处理都很不方便,因此“如何将方法的请求者与方法的实现者解耦?”变得很重要,命令模式能很好地解决这个问题。
在现实生活中,这样的例子也很多,例如,电视机遥控器(命令发送者)通过按钮(具体命令)来遥控电视机(命令接收者),还有计算机键盘上的“功能键”等。
使用场景
对于大多数请求——响应模式的功能,比较适合使用命令模式。
- 系统需要将请求调用者和请求接收者解耦,使得调用者和接收者不直接交互。
- 系统需要在不同的时间指定请求、将请求排队(如:线程池+工作队列)和执行请求。
- 系统需要支持命令的撤销(Undo)操作和恢复(Redo)操作(比如系统挂掉之后重启做一些恢复操作,还有数据库的事务等)。
- 系统需要将一组操作组合在一起,即支持宏命令。
优点
- 降低系统的耦合度。命令模式能将调用操作的对象与实现该操作的对象解耦。
- 增加或删除命令非常方便。采用命令模式增加与删除命令不会影响其他类,它满足“开闭原则”,对扩展比较灵活。
- 可以实现宏命令。命令模式可以与组合模式结合,将多个命令装配成一个组合命令,即宏命令。
- 方便实现 Undo 和 Redo 操作。命令模式可以与后面介绍的备忘录模式结合,实现命令的撤销与恢复。
缺点
可能产生大量具体命令类。因为计对每一个具体操作都需要设计一个具体命令类,这将增加系统的复杂性。
结构与实现
命令模式包含以下主要角色。
- 抽象命令类(Command):声明执行命令的接口,拥有执行命令的抽象方法 execute()。
- 具体命令角色(Concrete Command):是抽象命令类的具体实现类,它拥有接收者对象,并通过调用接收者的功能来完成命令要执行的操作。
- 实现者/接收者(Receiver):执行命令功能的相关操作,是具体命令对象业务的真正实现者。
- 调用者/请求者(Invoker):是请求的发送者,它通常拥有很多的命令对象,并通过访问命令对象来执行相关请求,它不直接访问接收者。
其结构图如下图所示。
命令模式的代码如下:
示例
用命令模式实现客户去餐馆吃早餐的实例。
分析:客户去餐馆可选择的早餐有肠粉、河粉和馄饨等,客户可向服务员选择以上早餐中的若干种,服务员将客户的请求交给相关的厨师去做。这里的点早餐相当于“命令”,服务员相当于“调用者”,厨师相当于“接收者”,所以用命令模式实现比较合适。
首先,定义一个早餐类(Breakfast),它是抽象命令类,有抽象方法 cooking(),说明要做什么;再定义其子类肠粉类(ChangFen)、馄饨类(HunTun)和河粉类(HeFen),它们是具体命令类,实现早餐类的 cooking() 方法,但它们不会具体做,而是交给具体的厨师去做;具体厨师类有肠粉厨师(ChangFenChef)、馄蚀厨师(HunTunChef)和河粉厨师(HeFenChef),他们是命令的接收者,所以把每个厨师类定义为 JFrame 的子类;最后,定义服务员类(Waiter),它接收客户的做菜请求,并发出做菜的命令。客户类是通过服务员类来点菜的,下图所示是其结构图。
程序代码如下:
实战
命令模式在 GUI 上应用广泛,比如手写签名功能,需要提供撤销或重做等功能。
- 首先声明一个抽象接口 IBrush,用它定义不同笔触需要实现的方法。
|
|
- 为了简便起见,这里只定义两种类型的笔触,一种为普通的线条,另一种为由圆点组成的线条轨迹。
|
|
- 对于每一次路径的绘制,都可以有两个命令,一个是绘制命令,另一个是撤销命令,我们将其封装为一个命令接口。注意,这里结合命令模式去构思。
|
|
- 这里只有一种绘制路径方法,即一个具体命令。
|
|
- 需要一个请求者角色(Invoker)来对命令做进一步封装。
|
|
- 需要一个具体的接收者,这里承担重任的是一个 SurfaceView 对象。
|
|
- 最后在 Activity 中整合各个功能模块。
|
|
res/layout/act_test.xml
效果图如下