命令模式

---

title: 命令模式
date: 2017-01-16 02:29:27
tags:

• 设计模式
• Java
  category: 设计模式

---

提到命令模式先别管他干什么，名字里有命令那肯定离不开命令，好的，开始编码：

commandSender.order();

写完收工！当然是不行的，要面向对象，要遵循设计模式的几大原则的。

（到底是几？我也不知道，有人说是五大原则，也有人说六大原则，还有说七大原则）

简单划分一下职责，很自然的就能想到三个角色：

1. 命令的发出者
2. 命令
3. 命令的接收者

Command command = commandSender.createCommend();
commandReceiver.execute(command);

《Head First 设计模式》中是以一个为多个电器设计通用遥控器的例子开始介绍命令模式的。

假如我们认为遥控器是命令的发出者，那么谁是命令的接收者呢？

我们无法根据命令就知道接受者到底是电视机，电灯还是其他。

那么就有两种选择了，

第一种：

Command command = commandSender.createCommand();
CommandReceiver commandReceiver = commandSender.getCommandReceiver();
commandReceiver.execute(command);

第二种：

Command command = commandSender.createCommandWithReceiver();
CommandReceiver commandReceiver = command.getReceiver();
commandReceiver.execute(command);

如果遥控器是命令的发出者，第一种方式将造成遥控器与电器紧密的耦合在一起。

当电器发生变化，遥控器也必须跟随发生变化，这就违反开闭原则。

第二种方式其实就是命令模式，只不过习惯上命令模式把命令发出者成为调用者。UML类图如下：

命令模式.png

调用者封装命令，命令的具体执行由调用者委托给具体的命令。

命令又封装了具体的命令接受者，命令的执行委托给命令的接受者。

整个命令的执行起来时序图如下：

命令模式时序图.png

除了遥控器的例子《Head First 设计模式》中还举了个餐厅订餐的例子，其中角色对应关系如下：

命令模式	遥控器	餐厅
客户端	用户	顾客
调用者	遥控器	女招待
命令	按钮	订单
命令接受者	电器	厨师

关于点餐的例子我觉得不是很恰当，当然也可能是我理解的不对，书上描述顾客创建订单，订单作为命令包含具体的命令接受者厨师，这点怎么都不能接受，谁家点餐的时候会关注厨师呢？

我的理解应该是顾客到店前，女招待，订单，厨师已经做好了准备。

顾客要下单时直接找女招待就可以了，由女招待根据订单找厨师做菜。

在通俗的说就是客户端只需要与调用者交互，不需要关心其他。其他部分的装配应给交给系统（例如，Spring）

理清了这层关系，我们把目光停留在调用者身上。

对于客户端来说，调用实际是从调用者这里发出的，换句话说，调用者实际上决定了命令实际的执行时机。

假设一个场景，调用者和命令的关系不是一对一，而是一对多。

当多个命令排队，依次等待调用者执行命令，这不就是队列请求模型？

---

命令模式的总结：

所属类别：行为模式

最大的优点：调用者与接受者的充分解耦

基于命令模式可以方便的做出如下扩展：

1. 调用者可以不知道接受者，甚至是不知道具体的命令，只需要预留接口；
2. 一个命令中可以由多个命令组成，当此命令被调用时可以，触发多个命令的调用：宏命令；
3. 方便命令执行前后增加切面，方便记录，回滚操作；
4. 延迟命令执行的时机：队列请求模式；

---

20180701记
回头再看，发现很多描述非常生涩。什么是命令模式？其实就是命令发出者与命令执行者之间的解耦，而解耦方式是通过增加了一个抽象的命令来实现的。
好吧，还是很难理解，举个例子：最近家里增加了小爱同学，我可以对小爱同学说“开灯”，台灯应声打开。这个场景下我是客户端，小爱同学是调用者，开灯是命令，台灯是命令的执行者。
如果又添加了小米电视，小爱同学（调用者）可以语音（命令）打开电视（命令执行者）。电视实现了小爱同学命令的执行接口（可以扩展）。而我不需要找电视机的遥控器（简化客户端调用，避免客户端与命令实现之间的耦合）。
有一天我的很多家电都接入小爱同学了，我说“我回来了”，台灯，电视，空调，热水器都打开了，这就是“宏命令”。