在阎宏博士的《JAVA与模式》一书中开头是这样描述命令（Command）模式的：命令模式属于对象的行为模式。命令模式又称为行动(Action)模式或交易(Transaction)模式。命令模式把一个请求或者操作封装到一个对象中。命令模式允许系统使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。
命令模式通过将用户的请求以命令对象的形式进行分装，然后将命令发送给具体的调用处理者。命令模式把发出命令的责任和执行命令的责任分割开，委派给不同的对象，因而达到命令的发送者和命令执行者之间的解耦。
UML图
命令模式.png
命令模式涉及到的五个角色：
- 抽象命令角色（Command）：定义声明所有命令指令类的规范行为。
- 具体命令角色（ConcreteCommand）：定义一个具体的命令角色，一般包含一个命令接受者的引用，通过在execute方法中调用具体的执行者进行执行。
- 接受者角色（Receiver）：该类负责具体实施或执行一个请求，充当了具体逻辑处理角色。
- 请求者角色（Invoker）：该类负责调用命令对象执行具体请求，相关的方法叫行动方法。
UML图不是固定的，在实际使用的过程中可随机应变，比如可以直接把Receiver定义成一个通用化的接受者来处理多个命令，或者通过工厂方法模式结合来处理多个命令的情况。
案例演示
我们都知道在小游戏中都存在上、下、左、右的操作指令，所以这次我们就以这种场景来模拟。
创建抽象Command指令和具体的指令
abstract class Command {
protected Receiver receiver;
public abstract void execute();
public void setReceiver(Receiver receiver) {
this.receiver = receiver;
}
}
class UpCommand extends Command{
@Override
public void execute() {
System.out.println("指令：向上");
receiver.doCommand();
}
}
class DownCommand extends Command{
@Override
public void execute() {
System.out.println("指令：向下");
receiver.doCommand();
}
}
定义接受者Receiver
abstract class Receiver {
public abstract void doCommand();
}
class UpReceiver extends Receiver{
@Override
public void doCommand() {
System.out.println("执行者：向上");
}
}
class DownReceiver extends Receiver{
@Override
public void doCommand() {
System.out.println("执行者：向下");
}
}
定义请求者角色Invoker
public class Invoker {
private Command command;
public Invoker(Command command) {
super();
this.command = command;
}
public void doCommand(){
command.execute();
}
}
定义客户端
public class Client {
/**
* @param args
*/
public static void main(String[] args) {
Command commandUp = new UpCommand();
commandUp.setReceiver(new UpReceiver());
Invoker invoker = new Invoker(commandUp);
invoker.doCommand();
}
}
上面就是一个命令模式的演示，在上面的模式中，通过继承实现多个对应类型的接收者，这里同样可以在一个接收者中完成。
优缺点
优点
- 类间解耦：调用者角色与接收者角色之间没有任何依赖关系，调用者实现功能时只需调用Command 抽象类的execute方法就可以，不需要了解到底是哪个接收者执行。在我的理解中，可以直接把Receiver在Command中指定好，而不一定要在客户端进行动态绑定。这样或许会省事一些，但是扩展性需要考虑。
- 可扩展性：Command的子类可以非常容易地扩展，而调用者Invoker和高层次的模块Client不产生严 重的代码耦合。
- 命令模式结合其他模式会更优秀：命令模式可以结合责任链模式，实现命令族解析任务；结合模板方法模式，则可以减少 Command子类的膨胀问题。
缺点
命令模式也是有缺点的，如果有N个命令，问题就出来 了，Command的子类就可不是几个，而是N个，这个类膨胀得非常大，这个就需要读者在项 目中慎重考虑使用。
