设计模式之禅笔记-命令模式

命令模式
命令模式是一个高内聚的模式；
定义：Encapsulate a request as an object,thereby letting you parameterize clients with 
different requests,queue or log requests,and support undoable operations.
将一个请求封装成一个对象，从而让你使用不同的请求把客户端参数化，对请求排队或者记录请求
日志，可以提供命令的撤销和恢复功能。

类图中有三个角色：
Receive接收者角色：
该角色就是干活的角色，命令传递到这里是应该被执行的；
Command命令角色：
需要执行的所有命令都在这里声明。
Invoker调用者角色：
接收到命令，并执行命令。

命令模式比较简单，但是在项目中非常频繁地使用，因为它的封装性非常好，把请求方(Invoker)和
执行方(Receiver)分开了，扩展性也有很好的保障，通用代码比较简单。

命令模式的优点：
类间解耦
调用者角色与接收者角色之间没有任何依赖关系，调用者实现功能时只须调用Command抽象类的
execute方法就可以，不需要了解了解到底是哪个接收者执行。
可扩展性
Command的子类可以非常容易地扩展，而调用者Invoker和高层次的模块Client不产生严重的代码
耦合。
命令模式结合其他模式会更优秀
命令模式可以结合责任链模式、实现命令族解析任务；结合模板方法模式，则可以减少Command子类
的膨胀问题。

命令者模式的缺点：
子类越多，这个类膨胀的就越大。

命令者模式的使用场景
只要你认为是命令的地方就可以采用命令模式。

命令模式的扩展
在项目中，对应客户更改需求，采用命令模式，只需客户发出更改命令，在类接收到命令后，自动
调用需求组添加需求，再调用开发，添加页面，功能和计划。
反悔问题的两种解决方案：
一是结合备忘录模式还原最后的状态：
该方法适合接收者为状态的变更情况，而不适合事件处理；
二是通过增加一个新的命令，实现事件的回滚。

最佳实践
我们可以再项目中通过有意义的类名或命令名处理命令角色和接收者角色的耦合关系(这就是约定)，
减少高层模块(Client类)对低层模块(Receiver角色类)的依赖关系，提高系统整体的稳定性。