设计模式（15） 命令模式（简单入门 行为模式）

设计图和源代码请访问我的github：https://github.com/yangsheng20080808/DesignModel

From Now On，Let us begin Design Patterns。

命令模式

定义

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

通用类图:

角色解说：

Command: 定义命令的接口，声明执行的方法。

ConcreteCommand：命令接口实现对象，是“虚”的实现；通常会持有接收者，并调用接收者的功能来完成命令要执行的操作。

Receiver：接收者，真正执行命令的对象。任何类都可能成为一个接收者，只要它能够实现命令要求实现的相应功能。

Invoker : 要求命令对象执行请求，通常会持有命令对象，可以持有很多的命令对象。这个是客户端真正触发命令并要求命令执行相应操作的地方，也就是说相当于使用命令对象的入口。

Client : 创建具体的命令对象，并且设置命令对象的接收者。注意这个不是我们常规意义上的客户端，而是在组装命令对象和接收者，或许，把这个Client称为装配者会更好理解，因为真正使用命令的客户端是从Invoker来触发执行。

通用源码实现如下：《设计模式之禅》

命令模式的优点：

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

• 新的命令可以很容易地加入到系统中
  Command的子类可以非常容易地扩展，而调用者Invoker和高层次的模块Client不产生严
  重的代码耦合。

• 可以比较容易地设计一个组合命令
  这甚至都不用说是它的优点，因为它太明显了。在现有的系统中增加一个策略太容易了，只要实现接口就可以了，其他都不用修改，类似于一个可反复拆卸的插件，这大大地符合了OCP原则。

命令模式的缺点：

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

命令模式的使用场景：

系统需要将请求调用者和请求接收者解耦，使得调用者和接收者不直接交互。

系统需要支持命令的撤销(Undo)操作和恢复(Redo)操作

命令模式的注意事项：

如果系统中的一个策略家族的具体策略数量超过4个，则需要考虑使用混合模式，解决策略类膨胀和对外暴露的问题，否则日后的系统维护就会成为一个烫手山芋，谁都不想接。

命令模式的例子：

模拟对空调的操作有开机、关机、调节温度。

类图：

执行命令的接口 ：

运行结果：