设计模式系列（九）命令模式(Command Pattern)

设计模式系列（九）命令模式(Command Pattern)

    命令模式是将请求封装成对象，以便使用不同的请求、队列或者日志来参数化其他对象，命令模式也支持可撤销的操作。命令模式将行为请求者与行为执行者解耦，从而实现了松耦合的原则。例如：去餐厅点餐的时候，顾客只负责点餐，然后交给服务员，服务员将订单交给厨师去做，最后顾客开始享用美味的饭菜，但是整个过程顾客只关心自己点了什么，而不关心餐厅到底是按照怎样的流程和方法做出这些菜的。再比如：遥控器上有很多按钮，每个按钮都相当于一个命令或者多个命令，当我们按下开机的时候，我们只关心电视是否开机了，而不关心也不知道到底是怎么开机的。这些例子中，顾客点菜以及用遥控器的人都是只请求一些行为，而具体的行为执行则是由其他执行的。

    命令模式中通常存在以下5个角色：

（1）Command角色：这个角色是接口或者抽象类，一般只有一个execute()函数留给子类去实现，有时候支持撤销操作的话会加上undo()函数，这个角色是所有具体命令的父类或者说是一个命令接口，并没有任何具体实现；

（2）ConcreteCommand角色：这个角色是抽象命令角色的具体实现类，实现其中的execute()函数，比如说在遥控器上的开机命令、关机命令等，这个具体命令类中，一般都需要有一个Receiver，用来执行真正的命令，再比如餐厅的订单就是命令；

（3）Receiver角色：接收者，真正执行命令的对象，任何类都可能成为一个接收者，只要它能够实现命令要求实现的相应功能，比如餐厅的厨师就是接收顾客的命令去做菜；

（4）Invoker角色：要求命令对象执行请求，通常会持有命令对象，可以持有很多的命令对象。这个是客户端真正触发命令并要求命令执行相应操作的地方，也就是说相当于使用命令对象的入口，例如餐厅的服务员就是接收顾客的命令然后使用ConcreteCommand对象交给厨师，再比如遥控器本身就是一个Invoker；

（5）Client角色：创建具体的命令对象，并且设置命令对象的接收者。注意这个不是我们常规意义上的客户端，而是在组装命令对象和接收者，或许，把这个Client称为装配者会更好理解，因为真正使用命令的客户端是从Invoker来触发执行，其创建一组命令然后交给Invoker去触发，最终通过ConcreteCommand让Receiver去执行。

    上面角色的大致关系是：Client创建一个ConcreteCommand对象并指定他的Receiver对象；然后某个Invoker对象存储该ConcreteCommand对象；该Invoker通过调用Command对象的Execute操作来提交一个请求。若该命令是可撤销的，ConcreteCommand就在执行Execute操作之前存储当前状态以用于取消该命令；ConcreteCommand对象对调用它的Receiver的一些操作以执行该请求。

    命令模式的优点是：

（1）降低对象之间的耦合度；
（2）新的命令可以很容易地加入到系统中；
（3）可以比较容易地设计一个组合命令；
（4）调用同一方法实现不同的功能。

    命令模式的缺点是：

    由于命令模式需要创建许许多多的具体命令类，每一个具体的命令都要创建一个对应的命令类，所以会导致系统中存在大量的具体命令类，使得系统对这个具体命令类的管理比较麻烦。比如：电视机遥控