背景
外面小摊与店面的比较，你就会发现，店面似乎更加容易管理，为什么呢？因为在客户与老板自己新增了很多员工，这些员工各司其职，所以井然有序，事情才会高效进行。这里有个重要的设计模式就是命令模式。
1、使用意图
在软件系统中，“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。但在某些场合，比如要对行为进行“记录、撤销/重做、事务”等处理，这种无法抵御变化的紧耦合是不合适的。在这种情况下，如何将“行为请求者”与“行为实现者”解耦？将一组行为抽象为对象，实现二者之间的松耦合。这就是命令模式（Command Pattern）。
2、生活实例
服务员就是客户与厨师之间的一种解耦，如果客户自己与厨师之间耦合，其实也是可以实现的，但是缺点就是厨师这个类已经违背了单一职责原则，我们应该让职责划分得更清楚一些，所以增加了服务员。
3、Java 例子（框架、JDK 、JEE）
暂时未发现，如果有同学发现可以修改
4、模式类图
图片引用自：http://www.cnblogs.com/devinzhang/archive/2012/01/06/2315235.html
- 接收者角色（Receiver）：负责调用具体命令角色，执行命令
- 命令角色（Command）：定义一个抽象接口，声明所有的命令方法
- 具体命令角色（Concrete Command）：实现命令角色接口，实现接口中的所有方法，这方法的实现就是命令所要求完成的功能。通常会持有接收者，并调用接收者的功能来完成命令要执行的操作。
- 请求者角色（Invoker）：要求命令对象执行请求，通常会持有命令对象，可以持有很多的命令对象。这个是客户端真正触发命令并要求命令执行相应操作的地方，也就是说相当于使用命令对象的入口。通过一个集合队列管理命令对象，对命令进行管理，诸如撤销、增加等功能。
- 客户角色（Client）：直接与接请求者角色联系，并且发出命令（所谓发出命令，实质就是定义一些具体命令角色的对象）。
5、模式优点
命令模式：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。
第一：它能较容易地设计一个命令队列；
第二：在需要的情况下，可以较容易地将命令记录日志；
第三：允许接收请求的一方决定是否要否决请求；
第四：可以容易地实现对请求的撤销和重做；
第五：由于加进新的具体命令类不影响其他的类，因此增加新的具体命令类很容易。
命令模式吧请求一个操作的对象与知道怎么执行一个操作的对象分割开。
6、与类似模式比较
不要为代码添加基于猜测的、实际不需要的功能。如果不清楚一个系统是否需要命令模式，一般不要急去实现它，事实上，在需要的时候通过重构实现这个模式并不困难，只有在真正需要如撤销、恢复操作等功能时，把原来的代码重构为命令模式才有意义。
命令模式感觉使用起来稍微有点复杂。