命令模式
![](https://storage.bummon.com//image/202307222149702.png)
命令模式
Bummon命令模式
一、定义
摘自百度百科: 在软件系统中,“行为请求者” 与 “行为实现者” 通常呈现一种 “紧耦合” 。但在某些场合,比如要对行为进行“记录、撤销/重做、事务”等处理,这种无法抵御变化的紧耦合是不合适的。在这种情况下,如何将“行为请求者”与“行为实现者”解耦?将 一组行为抽象为对象 , 实现二者之间的松耦合 。这就是 命令模式(Command Pattern)。
二、角色分类
抽象命令者(Command)
通常情况下为接口或抽象类,用于定义命令的接口,声明要执行的方法
具体命令者(Concrete Command)
其为命令者的子类,通常会有一个接收者,并调用接收者的方法来完成命令要执行的操作
抽象接收者/抽象实现者(Receiver)
真正要执行命令的对象
具体接收者/具体实现者(Concrete Receiver)
其类为抽象接收者的类,实现了在抽象接收者中定义的方法
调用者/请求者(Invoker)
要求命令对象执行请求,通常会持有命令对象,可以有很多的命令对象。这个类是客户端真正触发并要求命令执行相应操作的地方,相当于命令对象的入口
客户角色(Client)
具体调用方法的地方
三、实现方式
UML图
具体实现
我们可以使用一个简单的示例来深入的说明一下命令模式
抽象命令者(Command)
1 | public abstract class Command { |
调用者(Invoker)
1 | public class Invoker { |
具体命令者(Concrete Command)
1 | public class ConcreteCommand extends Command { |
抽象接收者(Receiver)
1 | public abstract class Receiver { |
具体接收者(Concrete Receiver)
1 | public class ConcreteReceiverA extends Receiver { |
客户角色(Client)
1 | public class Client { |
运行结果
1 | 接收者A收到命令 |
四、应用场景
以下部分内容摘自菜鸟教程
意图: 将一个请求封装成一个对象,从而使您可以用不同的请求对客户进行参数化。
主要解决: 在软件系统中,行为请求者与行为实现者通常是一种紧耦合的关系,但某些场合,比如需要对行为进行记录、撤销或重做、事务等处理时,这种无法抵御变化的紧耦合的设计就不太合适。
何时使用: 在某些场合,比如要对行为进行”记录、撤销/重做、事务”等处理,这种无法抵御变化的紧耦合是不合适的。在这种情况下,如何将”行为请求者”与”行为实现者”解耦?将一组行为抽象为对象,可以实现二者之间的松耦合。
如何解决: 通过调用者调用接受者执行命令,顺序:调用者→命令→接受者。
关键代码:
定义三个角色:
- received 真正的命令执行对象
- Command
- invoker 使用命令对象的入口
应用实例: struts 1 中的 action 核心控制器 ActionServlet 只有一个,相当于 Invoker,而模型层的类会随着不同的应用有不同的模型类,相当于具体的 Command。
使用场景: 认为是命令的地方都可以使用命令模式,比如:
- GUI 中每一个按钮都是一条命令。
- 模拟 CMD。
注意事项: 系统需要支持命令的撤销(Undo)操作和恢复(Redo)操作,也可以考虑使用命令模式,见命令模式的扩展。
五、优缺点
优点
- 降低了系统耦合度。
- 新的命令可以很容易添加到系统中去。
缺点
使用命令模式可能会导致某些系统有过多的具体命令类。