系列文章
【设计模式】七大设计原则
【设计模式】第一章：单例模式
【设计模式】第二章：工厂模式
【设计模式】第三章：建造者模式
【设计模式】第四章：原型模式
【设计模式】第五章：适配器模式
【设计模式】第六章：装饰器模式
【设计模式】第七章：代理模式
【设计模式】第八章：桥接模式
【设计模式】第九章：外观模式 / 门面模式
【设计模式】第十章：组合模式
【设计模式】第十一章：享元模式
【设计模式】第十二章：观察者模式
【设计模式】第十三章：模板方法模式
【设计模式】第十四章：策略模式
【设计模式】第十五章：责任链模式
【设计模式】第十六章：迭代器模式
【设计模式】第十七章：状态模式
【设计模式】第十八章：备忘录模式
【设计模式】第十九章：访问者模式
【设计模式】第二十章：解释器模式
【设计模式】第二十一章：命令模式
【设计模式】第二十二章：中介者模式
文章目录
- 系列文章
- 命令模式
- 一、定义
- 二、角色分类
- 三、实现方式
- UML图
- 具体实现
- 四、应用场景
- 五、优缺点
- 优点
- 缺点
命令模式
一、定义
摘自百度百科： 在软件系统中，“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。但在某些场合，比如要对行为进行“记录、撤销/重做、事务”等处理，这种无法抵御变化的紧耦合是不合适的。在这种情况下，如何将“行为请求者”与“行为实现者”解耦？将一组行为抽象为对象，实现二者之间的松耦合。这就是命令模式（Command Pattern）。
二、角色分类
抽象命令者（Command）
通常情况下为接口或抽象类，用于定义命令的接口，声明要执行的方法
具体命令者（Concrete Command）
其为命令者的子类，通常会有一个接收者，并调用接收者的方法来完成命令要执行的操作
抽象接收者/抽象实现者（Receiver）
真正要执行命令的对象
具体接收者/具体实现者（Concrete Receiver）
其类为抽象接收者的类，实现了在抽象接收者中定义的方法
调用者/请求者（Invoker）
要求命令对象执行请求，通常会持有命令对象，可以有很多的命令对象。这个类是客户端真正触发并要求命令执行相应操作的地方，相当于命令对象的入口
客户角色（Client）
具体调用方法的地方
三、实现方式
UML图
具体实现
我们可以使用一个简单的示例来深入的说明一下命令模式
抽象命令者（Command）
public abstract class Command {
public abstract void execute();
}
调用者（Invoker）
public class Invoker {
private Command command;
public void Invoker(Command command) {
this.command = command;
}
public void setCommand(Command command) {
this.command = command;
}
public void call() {
command.execute();
}
}
具体命令者（Concrete Command）
public class ConcreteCommand extends Command {
private Receiver receiver;
public ConcreteCommand(Receiver receiver) {
super();
this.receiver = receiver;
}
public void execute() {
receiver.action();
}
}
抽象接收者（Receiver）
public abstract class Receiver {
public abstract void action();
}
具体接收者（Concrete Receiver）
public class ConcreteReceiverA extends Receiver {
@Override
public void action() {
System.out.println("接收者A收到命令");
}
}
public class ConcreteReceiverB extends Receiver {
@Override
public void action() {
System.out.println("接收者B收到命令");
}
}
客户角色（Client）
public class Client {
public static void main(String[] args) {
Receiver receiverA = new ConcreteReceiverA();
Command command1 = new ConcreteCommand(receiverA);
Invoker invoker = new Invoker();
invoker.setCommand(command1);
invoker.call();
Receiver receiverB = new ConcreteReceiverB();
Command command2 = new ConcreteCommand(receiverB);
invoker.setCommand(command2);
invoker.call();
}
}
运行结果
接收者A收到命令
接收者B收到命令
四、应用场景
以下部分内容摘自菜鸟教程
意图： 将一个请求封装成一个对象，从而使您可以用不同的请求对客户进行参数化。
主要解决： 在软件系统中，行为请求者与行为实现者通常是一种紧耦合的关系，但某些场合，比如需要对行为进行记录、撤销或重做、事务等处理时，这种无法抵御变化的紧耦合的设计就不太合适。
何时使用： 在某些场合，比如要对行为进行"记录、撤销/重做、事务"等处理，这种无法抵御变化的紧耦合是不合适的。在这种情况下，如何将"行为请求者"与"行为实现者"解耦？将一组行为抽象为对象，可以实现二者之间的松耦合。
如何解决： 通过调用者调用接受者执行命令，顺序：调用者→命令→接受者。
关键代码：
定义三个角色：
1. received 真正的命令执行对象
2. Command
3. invoker 使用命令对象的入口
应用实例： struts 1 中的 action 核心控制器 ActionServlet 只有一个，相当于 Invoker，而模型层的类会随着不同的应用有不同的模型类，相当于具体的 Command。
使用场景： 认为是命令的地方都可以使用命令模式，比如：
1. GUI 中每一个按钮都是一条命令。
2. 模拟 CMD。
注意事项： 系统需要支持命令的撤销(Undo)操作和恢复(Redo)操作，也可以考虑使用命令模式，见命令模式的扩展。
五、优缺点
优点
- 降低了系统耦合度。
- 新的命令可以很容易添加到系统中去。
缺点
使用命令模式可能会导致某些系统有过多的具体命令类。
