命令模式：将“请求”封装成对象，以便使用不同的请求、队列或者日志来参数化其他对象。命令模式也支持可撤销的操作。
模式类图：
下面举一个具体的例子：
有一个遥控器类RemoteControl，它可以控制Light类的行为，一个Command命令接口，两个实现Command接口的具体命令，分别实现开灯、关灯命令。
客户Client在使用这个遥控器的时候，先实例化一个RemoteControl类，如果它要开灯，那么就实例化LightOnCommand具体命令，将要控制的Light对象传入，调用setCommand方法将命令传给RemoteControl，当调用RemoteControl的commandExcute方法时，就能实现开灯的功能了。
这样的好处是什么？将遥控器的类，与Light厂商的类解耦了，这样一来，遥控器代码能尽可能的简单，新的厂商类一旦出现，遥控器不需要更改代码，只要该厂商类实现同样的Command接口属于自己的命令类，在实例化的时候传入自己的具体命令类，那么程序就能正确运行，完全不需要更改已经写好的代码。对扩展（新增厂商类）开放，对修改关闭，符合开闭原则。
如果要实现撤销功能，只需要在具体命令类加一个Command对象来记录上一次执行的命令，如果要实现连续撤销的功能，那么就加一个Command对象的List来记录所有执行过的命令。
如果要实现控制灯的同时，又控制电视，控制空调，怎么办？把RemoteControl的Command对象该成List，传入一组命令，execute的时候，遍历命令列表，逐个执行命令就可以了。
命令模式的更多用途：
1.队列请求
有一个工作队列，在某一端添加命令，另一端是线程。线程执行下面动作：从队列中取出一个命令，调用它的execute方法，等待这个调用完成，然后将此命令丢弃，再取出下一个命令。甚至在多线程的环境中也能应用，只要在操作队列的时候讲队列加锁，取出命令后，再解锁，让其他空闲的线程进行同样的操作，这是所谓的线程池。
工作队列的命令类与命令的实现者是完全解耦的，此刻线程可能进行财务运算，下一刻可能在进行读取网络数据，工作队列不在乎命令对象到底要做什么，只要它实现了Command接口，就能放进队列。
2.日志请求
某些应用需要将所有的动作都记录在日志中，并能在系统死机后，重新调用这些动作恢复到之前的状态，通过新增store、load两个方法，就能支持这一点。当我们执行命令的时候，调用store方法，将历史记录在磁盘中，一旦系统死机，就可以将命令load重载，并一次调用这些对象的execute方法。许多调用大型数据结构的动作的应用无法在每次改变时快速地存储。通过记录日志，可以将上次检查点之后的所有操作记录下来，如果出现问题，就从检查点开始重新执行操作，检查点是能确保之前的操作全部执行成功的一个时间点。
3.事物处理
跟日志请求类似，在事务执行前设置一个检查点，事物执行后设置另一个检查点，如果两个检查点完整，就代表这次事物执行完了，如果不完整，事务执行过程失败，必须回滚重新执行。