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