命令模式
title: 命令模式
date: 2017-01-16 02:29:27
tags:
- 设计模式
- Java
category: 设计模式
提到命令模式先别管他干什么，名字里有命令那肯定离不开命令，好的，开始编码：
commandSender.order();
写完收工！当然是不行的，要面向对象，要遵循设计模式的几大原则的。
（到底是几？我也不知道，有人说是五大原则，也有人说六大原则，还有说七大原则）
简单划分一下职责，很自然的就能想到三个角色：
- 命令的发出者
- 命令
- 命令的接收者
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）
理清了这层关系，我们把目光停留在调用者身上。
对于客户端来说，调用实际是从调用者这里发出的，换句话说，调用者实际上决定了命令实际的执行时机。
假设一个场景，调用者和命令的关系不是一对一，而是一对多。
当多个命令排队，依次等待调用者执行命令，这不就是队列请求模型？
命令模式的总结：
所属类别：行为模式
最大的优点：调用者与接受者的充分解耦
基于命令模式可以方便的做出如下扩展：
- 调用者可以不知道接受者，甚至是不知道具体的命令，只需要预留接口；
- 一个命令中可以由多个命令组成，当此命令被调用时可以，触发多个命令的调用：宏命令；
- 方便命令执行前后增加切面，方便记录，回滚操作；
- 延迟命令执行的时机：队列请求模式；
20180701记
回头再看，发现很多描述非常生涩。什么是命令模式？其实就是命令发出者与命令执行者之间的解耦，而解耦方式是通过增加了一个抽象的命令来实现的。
好吧，还是很难理解，举个例子：最近家里增加了小爱同学，我可以对小爱同学说“开灯”，台灯应声打开。这个场景下我是客户端，小爱同学是调用者，开灯是命令，台灯是命令的执行者。
如果又添加了小米电视，小爱同学（调用者）可以语音（命令）打开电视（命令执行者）。电视实现了小爱同学命令的执行接口（可以扩展）。而我不需要找电视机的遥控器（简化客户端调用，避免客户端与命令实现之间的耦合）。
有一天我的很多家电都接入小爱同学了，我说“我回来了”，台灯，电视，空调，热水器都打开了，这就是“宏命令”。
