一、概述
将一个请求封装为一个队形,从而使你可用不同的请求对客户进行参数化;对请求排队或记录请求日志,以及支持可撤销的操作。这就是命令模式(Command Pattern)。
二、模式结构
Command:
定义命令的接口,声明执行的方法。
ConcreteCommand:
命令接口实现对象,是“虚”的实现;通常会持有接收者,并调用接收者的功能来完成命令要执行的操作。
Receiver:
接收者,真正执行命令的对象。任何类都可能成为一个接收者,只要它能够实现命令要求实现的相应功能。
Invoker:
要求命令对象执行请求,通常会持有命令对象,可以持有很多的命令对象。这个是客户端真正触发命令并要求命令执行相应操作的地方,也就是说相当于使用命令对象的入口。
Client:
创建具体的命令对象,并且设置命令对象的接收者。注意这个不是我们常规意义上的客户端,而是在组装命令对象和接收者,或许,把这个Client称为装配者会更好理解,因为真正使用命令的客户端是从Invoker来触发执行。
模式结构图如下:
三、优缺点
优点:
1、较容易地设计一个命令队列
2、在需要情况下,可以较容易地将命令记入日志。
3、允许接受请求的一方决定是否要否决请求
4、可以容易地实现对请求的撤销和重做。
5、由于加进新的具体命令类不影响其他类,因此增加新的具体命令类很容易。
缺点:
使用命令模式可能会导致某些系统有过多的具体命令类。因为针对每一个命令都需要设计一个具体命令类因此某些系统可能需要大量的具体命令类。这就影响了命令模式的使用
总结
敏捷开发的原则告诉我们,不要为代码添加基于猜测的、实际不需要的功能如果不清楚一个系统是否需要命令模式,一般就不要着急去实现它。