《设计模式之禅》笔记摘录 - 8.命令模式

命令模式的定义

命令模式是一个高内聚的模式，其定义为：

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

命令模式的通用类图如图所示。

在该类图中，我们看到三个角色：

Receiver。接收者角色该角色就是干活的角色，命令传递到这里是应该被执行的。

Command。命令角色需要执行的所有命令都在这里声明。

Invoker。调用者角色接收到命令，并执行命令。

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

命令模式的应用

命令模式的优点

类间解耦。调用者角色与接收者角色之间没有任何依赖关系，调用者实现功能时只需调用Command抽类的execute方法就可以，不需要了解到底是哪个接收者执行。

可扩展性。Command的子类可以非常容易地扩展，而调用者Invoker和高层次的模块Client不产生严重的代码耦合。

命令模式结合其他模式会更优秀，命令模式可以结合责任链模式，实现命令族解析任务；结合模板方法模式，则可以减少command子类的膨胀问题。

命令模式的缺点

命令模式也是有缺点的，请看Command的子类：如果有N个命令，问题就出来了，Command的子类就可不是几个，而是N个，这个类膨胀得非常大，这个就需要在项目中慎重考虑使用。

命令模式的使用场景

只要你认为是命令的地方就可以采用命令模式，例如，在GUI开发中，一个按钮的点击是个命令，可以采用命令模式；模拟DOS命令的时候，当然也要采用命令模式；触发——反馈机制的处理等，

最佳实践

一个模式到实际应用的时都有一些变形，命令模式的Receiver在实际应用中一般都会被封装掉（除非非常必要，例如当处理），那是因为在项目中：约定的优先级最高，每一个命令是对一个或多个Receiver的封装，我们可以在项目中通过有意义的类名或命令名处理命令角色和接收者角色的耦合关系（这就是约定），减少高层模块(Client类）对低层模块(Receiver角色类）的依赖关系，提高系统整体的稳定性。

因此，建议大家在实际的项目开发时采用封闭Receiver的方式（当然了，仁者见仁，智者见智），减少Client对Reciver的依赖，该方案只是对Command抽象类及其子类有一定的修改，