设计模式系列（七）——命令模式

序

命令模式，将一个命令封装为一个对象，使得客户程序可以通过统一的命令接口来使用命令，而不必知道命令的实现细节。并且可以对命令的顺序进行排序和记录，以实现撤销功能。

动机和结构

在某些时候，接收请求的对象，并不知道如何执行请求。或者，设计者并不希望其知道如何执行请求。这是将命令封装为对象，这个对象与其他对象相同，可以被存储和传递。这样就实现了接收命令的对象与真正的命令操作之间的解耦。
更进一步，将所有的命令抽象出相同的接口，这样对于命令的更新和替换就更加的灵活。具体来讲，抽象出一个 Command 类，它定义了执行命令的接口。Command 的子类实现此接口，指定命令接受者采取相应的动作。
其结构图如下：

有时，一个命令需要执行一系列的命令。对于这种通用的需求，定义一个 MacroCommand 的子类，它按顺序存储多个 Command 的子类，并按顺序一次调用他们的接口。
如此的设计，使得在设计命令相关的内容（比如用户界面）时，拥有很好的灵活性。这一切的根源，就是因为提交一个命令请求的对象只需要知道如何提交请求，而不需要知道如何执行真正的命令。

使用时机

• 作为回调机制的面向对象的替代品
• 在不同的时刻指定、排列和执行请求。如果一个请求的接收者可用一种与地址空间无关的方式表达,那么就可将负 责该请求的命令对象传送给另一个不同的进程并在那儿实现该请求。
• 用于支持撤销操作。Command 对象可以保存一个状态列表，并添加一个撤销操作接口。
• 用于支持重放日志。
• 用于支持事务。因为一致的接口，所以可以方便的用一系列命令构建一个事务。

工作方法

组件

• Command: 声明执行操作的接口
• ConcreteCommand: 将一个接收者对象绑定于一个操作，调用接收者相应的操作,以实现接口
• Client: 创建一个具体命令对象并设定它的接收者
• Invoker: 要求该命令执行这个请求
• Receiver: 知道如何实施与执行一个请求相关的操作。任何类都可能作为一个接收者

协作

• Client创建一个ConcreteCommand对象并指定它的Receiver对象
• 某Invoker对象存储该ConcreteCommand对象。
• 该Invoker通过调用Command对象的Execute操作来提交一个请求。若该命令是可撤消的, ConcreteCommand就在执行Excute操作之前存储当前状态以用于取消该命令。
• ConcreteCommand对象对调用它的Receiver的一些操作以执行该请求。

优缺点

优点

• Command模式将调用操作的对象与知道如何实现该操作的对象解耦。
• Command是一类对象。它们可像其他的对象一样被操纵和扩展。
• 你可将多个命令装配成一个复合命令。例如是前面描述的 MacroCommand类。一般说来,复合命令是Composite模式的一个实例。
• 增加新的Command很容易,因为这无需改变已有的类。

实现要点

• 如何界定一个命令对象的智能程度。一个极端：仅知道接受者和执行的动作。另一个极端：全部命令都在命令对象中执行。折衷：可以动态的获取接受者。
• 支持撤销和重做命令的方法。需要存储一下信息：
  
  • 接收者对象,它真正执行处理该请求的各操作。
  • 接收者上执行操作的参数。
  • 如果处理请求的操作会改变接收者对象中的某些值,那么这些值也必须先存储起来。接收者还必须提供一些操作,以使该命令可将接收者恢复到它先前的状态。
  • 若支持多次撤销，还需要一个存储这些信息的列表。
• 避免取消操作过程中的错误积累，可以使用Memento模式