1. 定义
命令模式是一个高内聚的模式,其定义为:Encapsulate a request as an object , thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.(将一个请求封装成一个对象,从而让你使用不同的请求把客户端参数化,对请求排队或者记录请求日志,可以提供命令的撤销和恢复功能。)
2. 通用类图
在该类图中,我们看到三个角色:
- Receiver接受者角色
该角色就是干活的角色,命令传递到这里是应该被执行的,具体到我们上面的例子中就是Group的三个实现类。
- Command命令角色
需要执行的所有命令都在这里声明
- Invoker调用者角色
接收到命令,并执行命令。
3. 代码实现
命令模式比较简单,但是在项目中非常频繁地使用,因为它的封装性非常好,把请求方(Invoker)和执行方(Receiver)分开了,扩展性也有很好的保障,通用代码比较简单。
通用Receiver类
package CommandPattern;
public abstract class Receiver {
//抽象接受者,定义每个接受者都必须完成的业务
public abstract void doSomething();
}
很奇怪,为什么Receiver是一个抽象类?那是因为接受者可以有多个,有多个就需要定义一个所有特性的抽象集合-抽象的接受者,其具体的接受者如下所示:
package CommandPattern;
public class ConcreteReceiver1 extends Receiver{
//每个接受者都必须处理一定的业务逻辑
public void doSomething()
{
}
}
package CommandPattern;
public class ConcreteReceiver2 extends Receiver{
//每个接受者都必须处理一定的业务逻辑
public void doSomething()
{
}
}
接受者可以有N个,这要依赖业务的具体含义。命令角色是命令模式的核心,其抽象的命令类如下一样:
package CommandPattern;
public abstract class Command {
//每个命令类都必须有一个执行命令的方法
public abstract void execute();
}
根据环境的需求,具体的命令类也可以有N个,其实现类如下所示:
package CommandPattern;
public class ConcreteCommand1 extends Command{
//对哪个Receiver类进行命令处理
private Receiver receiver;
//构造函数传递接受者
public ConcreteCommand1(Receiver _receiver)
{
this.receiver=_receiver;
}
//必须实现一个命令
public void execute()
{
this.receiver.doSomething();
}
}
package CommandPattern;
public class ConcreteCommand2 extends Command{
//对哪个Receiver类进行命令处理
private Receiver receiver;
//构造函数传递接受者
public ConcreteCommand2(Receiver _receiver)
{
this.receiver=_receiver;
}
//必须实现一个命令
public void execute()
{
this.receiver.doSomething();
}
}
定义了两个具体的命令类,读者可以在实际应用中扩展该命令类。在每个命令类中,通过构造函数定义了该命令是针对哪一个接受者发出的,定义一个命令接收的主体。调用者非常简单,仅实现命令的传递。
调用者Invoker类
package CommandPattern;
public class Invoker {
private Command command;
//接收包,接收命令
public void setCommand(Command _command) {
this.command = _command;
}
//接收命令
public void action()
{
this.command.execute();
}
}
调用者就像受气包,不管什么命令,都要接收、执行。下面的代码时调用命令模式。
package CommandPattern;
public class Client {
public static void main(String[] agrs)
{
//首先声明调用者Invoker
Invoker invoker=new Invoker();
//定义接收者
Receiver receiver=new ConcreteReceiver1();
//定义一个发给接收者的命令
Command command=new ConcreteCommand1(receiver);
//把命令交给调用者去执行
invoker.setCommand(command);
invoker.action();
}
}
3. 命令模式的应用
3.1 命令模式的优点:
- 类间解耦
调用者角色与接受者角色之间没有任何依赖关系,调用者实现功能时只需要调用Command抽象类的execute方法就可以,不需要了解到底是哪个接收者执行的;
- 可扩展性
Command的子类非常容易扩展,而调用者Invoker和高层次的模块Client不产生严重的代码耦合
- 命令模式结合其他模式会更优秀
命令模式可以结合责任链模式,实现命令族解析任务;结合模板方法模式,则可以减少Command子类的膨胀问题。
3.2 命令模式的缺点
命令模式也是有缺点的,请看Command子类:如果有N个命令,问题就出来了,Command的子类可不是几个,而是N个,这个类膨胀得非常大,这个就需要慎重考虑了。
3.3 命令模式的使用场景
只要你认为是命令的地方就可以使用命令模式。例如,在GUI的开发中,一个按钮点击是一个命令,可以采用命令模式;模拟DOS命令的时候,当然也要采用命令模式;触发-反馈机制的处理等。
4. 命令模式的扩展
反悔问题,有两种方法可以解决:一是结合备忘录模式还原最后状态,该方法适合接受者为状态的变更情况,而不适合事件处理;而是通过增加一个新的命令,实现事件的回滚。