先上headfirst的类图和代码：
- 具体接收者类：
public class TV {
public void on(){}
public void off(){}
public void setInputChannel(){}
public void setVolume(){}
}
public class CeilingFan {
public void high(){}
public void medium(){}
public void low(){}
public void off(){}
public void getSpeed(){}
}
public class OutDoorLight {
public void on(){}
public void off(){}
}
- 命令类
public interface Command {
public void execute();
public void undo();
}
public class LightOnCommand implements Command {
Light light;
public LightOnCommand(Light light){
this.light = light;
}
@Override
public void execute() {
light.on();
}
@Override
public void undo() {
light.off();
}
}
- 控制器类
public class RemoteControl {
Command[] onCommands;
Command[] offCommands;
// 前一个命令将被记录在这里
Command undoCommand;
public RemoteControl() {
onCommands = new Command[7];
offCommands = new Command[7];
Command noCommand = new NoCommand();
for (int i = 0; i < 7; i++) {
onCommands[i] = noCommand;
offCommands[i] = noCommand;
}
// 一开始并没有所谓的“前一个命令”，所以将它设置成NoCommand
undoCommand = noCommand;
}
public void setCommand(int slot, Command onCommand, Command offCommand) {
onCommands[slot] = onCommand;
offCommands[slot] = offCommand;
}
// 当按下按钮，我们取得这个命令，并优先执行它，然后将它记录在undoCommand中。
public void onButtonWasPushed(int slot){
onCommands[slot].execute();
undoCommand = onCommands[slot];
}
public void offButtonWasPushed(int slot){
offCommands[slot].execute();
undoCommand = offCommands[slot];
}
// 当按下撤销按钮，我们调用undoCommand实例变量的undo()方法，就可以倒转前一个命令
public void undoButtonWasPushed(){
undoCommand.undo();
}
}
- 客户端类，略
如果不使用命令模式
public class RemoteControl {
TV tv = new TV();
... //创建一堆实际执行操作的类
public void onButtonWasPushed(int slot){
if(slot == 1){
tv.on();
}else if() //....一堆if else判断
}
}
1.RemoteControl直接依赖所有具体执行类，高度耦合。
2.如果现在需要新增或者删除一种操作，必须修改RemoteControl，并在if else中添加或删除一条分支，很难扩展
3.每个遥控器插槽和具体操作已经绑死，无法在运行时变更。
4.要实现undo不是很优雅，虽然也可以存储最后一次按键的slot和按键类型(on or off)来进行undo，代码将会又臭又长，极难维护(因为有的比如吊扇他的转速有五档。。。)
5.要实现多种操作组合也比较困难，能想到的方式是：妈的，想不到啥能说出口的。。。
命令模式到底怎么牛逼了
- 从最前面的客户（披萨店顾客）到命令控制者（服务员）到命令实际执行者（厨师），他们相互之间从来不直接说出自己的需求，从头至尾都是以命令对象（订单）说话，所以一个订单将他们的相互依赖完全解耦。
- 上面的例子中命令可能是一个一个单独存在并永久可以重复使用的，也可以实现以队列来存储命令，命令控制者一个个取出来执行。
- 写一个通用的组合式命令类，就可以无限复用实现任意组合的命令.
public class MultiCommand implements Command {
private Command[] commands;
public MultiCommand(Command[] commands){
this.commands = commands;
}
@Override
public void execute() {
for(Command command : commands){
command.execute();
}
}
@Override
public void undo() {
for(Command command : commands){
command.undo();
}
}
}
- 将一系列操作抽象成命令对象后，他能被序列化，存到日志，数据库等地方，当系统出现问题时，可以将命令列表拉出来进行undo或redo，数据库事务等。如果不用命令，每一次操作就必须保存一次原始数据快照，空间将会无比的浪费。
一些问题
命令对象中直接实现业务逻辑不行吗，为什么需要一个接受者？其实这样实现也可以，解耦成都就不如把接受者提出来了，而且以组合接收者的方式实现，运行时也是可以进行动态改变的。
多层次的undo操作如何实现？将只记录最后一次操作的command改为使用栈实现，每次undo从栈顶弹出一个元素执行undo操作即可，但是有个问题是需要控制栈的大小，无限制的往栈里添加元素一定会有问题。
宏命令方式实现功能组合，为什么用多个command组合，不直接调用具体执行类实现各自的方法？扩展性太差，这样做就相当于写死了，如果有另外一种组合的需求就必须新增一个类来实现，command组合以command数组传入的形式能应付任意的组合场景而不用修改现有代码。
headfirst以及各种设计模式书籍中的例子中，reciver类执行方法都是无参的，所以实现命令模式特别精简清洁，如果每一个reciver类的参数不一样该怎么办？首先，不能将传参这个动作设计在execute方法里，设计在execute方法里会导致下面的场景出现
public interface ICommand<T> {
void execute(T parameter);
}
//或者
public interface ICommand<T> {
void execute(Object... parameter);
}
这样一来invoke类就必须了解每个command的参数类型等逻辑，所谓的命令模式解耦就完全被破坏了，所以应该将参数放在每个command内部，通过构造器或者setter方式设值，设值动作则由client类进行。
public class ParamterCommand implements Command {
private TV tv;
private long time; //灯开多久，参数通过构造器注入
public MultiCommand(TV tv, long time){
this.tv = tv;
}
@Override
public void execute() {
tv.on(this.time);
}
@Override
public void undo() {
//....
}
}
- 如果命令需要有返回值呢，毕竟head first书中的点餐例子中，客人下了单了，服务员通知厨师了，厨师也按照菜单做菜了，那做完了总得给客人吃吧？ 有返回值就必须在execute方法上返回了，如果返回值能抽象化(返回值都属于同一种类型)，直接把
void execute();改为AbstractResult execute();即可。不能抽象调用者和接受者之间就存在比较大的耦合了，调用者需要知道接收者的具体返回类型。----------------------其实命令模式更多的用处在于调用者只需要发出命令，调用者不知道具体执行者什么时候怎么执行，所以对于返回值也应该是这样的:厨师做好东西后继续弃用另外一套命令模式，之前阶段的命令模式传的是菜单，当前启用的命令模式传递的是做好的一堆菜，甚至可以做好一盘上一盘。当然也可以考虑使用观察者模式来进行后续上菜操作。
命令模式使用场景
- 遥控器例子(经典实现)
- 日志请求
- 工作队列
and so on..........
