一.定义
将一个请求封装成一个对象，从而让你使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。
二.类图
- Receiver接受者角色，命令执行角色。
- Command命令角色，需要执行的所有命令都在这里声明。
- Invoker调用者角色，接受到命令，并执行命令。
三.优点
- 类间解耦。调用者角色与接受者角色之间没有任何依赖关系，调用者实现功能时只须调用Command抽象类execute方法就可以，不需要了解到底是哪个接受者执行。
- 可扩展性。Command的子类可以非常容易地扩展。
- 命令模式结合其他其他模式会更优秀。命令模式结合责任链模式，实现命令族解析任务；结合模版方法模式，则可以减少Command子类的膨胀问题。
四.缺点
Command子类多时，会造成类膨胀问题。
五.使用场景
只要你认为是命令的地方就可以采用命令模式。
六.注意事项
每一个模式到实际应用的时候都有一些变形，命令模式的Receiver在实际应用一般会被封装掉（除非非常必要，例如撤销处理），那是因为在项目中：约定的优先级最好，每一个命令是对一个或多个Receiver的封装，我们可以在项目中通过有意义的类名或命令名处理命令角色和接收者角色的耦合关系（这就是约定），较少高层模块Client类对低层模块Receiver角色类的依赖关系，提高系统整体的稳定性。
