概述
命令模式是行为型设计模式之一.我们接触较多的命令模式个例无非就是程序菜单命令.
如我们执行 关机
命令,系统就会执行一些列操作(如暂停处理事件,保存系统配置,结束进程等),对于这一系列命令,用户不用去管,用户只需要点击系统的关机按钮即可完成如上一系列命令.
命令模式其实就是将一系列的方法调用封装,用户只需要调用一个方法执行即可.
定义
将一个请求封装成一个对象,从而让用户使用不同的请求把客户端参数化,对请求排队或者记录请求日志,以及支持可撤销的操作.
使用场景
- 需要抽象出待执行的动作,然后以参数的形式提供出来 – 类似过程设计中的回调机制.而命令模式正是回调机制的一个面向对象的替代品.
- 在不同的时刻指定,排列和执行请求.一个命令对象可以有与初始请求无关的生存期
- 需要支持取消操作
- 支持修改日志功能,这样当系统崩溃时,这些修改可以被重做一遍
- 需要支持事务
UML类图
命令模式中的角色
- Receiver : 接收者角色,该类负责实施或者执行一个请求,就是执行具体逻辑的角色.
- Command : 命令角色.定义了抽象命令接口.
- ConcreteCommand : 具体命令角色.实现了
Command
接口,在执行操作中调用接收者角色的相关方法.在接收者和命令执行者之间加以耦合. - Invoker : 请求者角色,调用命令对象执行具体的请求.相关的方法我们称之为行动方法.
- Client : 客户端角色
命令模式将行为调用者与实现者解耦
实例
命令模式中将一个简单的调用关系解耦成多个部分,会一个程度的增加类的复杂度,但是结构却很清晰.
实现一个简单的命令模式一般由如下步骤,
- 定义抽象命令接口
Command
public interface Command {
//执行具体的命令
void execute();
}
- 定义接收者
Receiver
public class Receiver {
//真正执行具体命令逻辑的方法
public void doAction(){
System.out.print("执行具体的操作");
}
}
- 具体命令类
public class ConcreteCommand implements Command {
private Receiver mReceiver;
@Override public void execute() {
//调用接收者的方法来执行命令
mReceiver.doAction();
}
public ConcreteCommand(Receiver receiver) {
mReceiver = receiver;
}
}
- 请求者类
public class Invoker {
private Command mCommand;//持用一个命令对象
public Invoker(Command command) {
mCommand = command;
}
public void action(){
mCommand.execute();
}
}
- 请求者调用相关命令执行,而命令则持有接收者对象,并调用接收者的相关方法执行命令.
- 一般在实际使用中,我们会抽象一个
IReceiver
出来,而具体的Receiver
实现IReceiver
接口或抽象类.
优缺点
缺点
- 和所有设计模式一样,命令模式也会使类的数目增多.当命令有多个的时候,就会非常明显.
优点
- 命令模式中,调用者与接收者之间没有依赖关系,降低耦合性.
- 有多个命令时,只需要扩展
Command
即可.很好的做到了对修改关闭,对扩展开发的原则. - 可以比较容易地设计一个命令队列和宏命令(组合命令).
- 可以方便地实现对请求的
Undo
和Redo
.