专栏目录
- 创建型模式: 工厂三兄弟 , 单例模式 , 原型模式 , 建造者模式
- 结构型模式: 适配器模式 , 桥接模式 , 组合模式 , 装饰器模式, 外观模式(门面模式), 享元模式, 代理模式
- 行为型模式: 职责链模式, 命令模式, 解释器模式, 迭代器模式, 中介者模式, 备忘录模式, 观察者模式, 状态模式, 策略模式, 模板方法, 访问者模式
命令模式的意图,解决的问题,什么时候使用
在软件开发系统中,“方法的请求者”与“方法的实现者”之间经常存在紧密的耦合关系,这不利于软件功能的扩展与维护。例如,想对方法进行“撤销、重做、记录”等处理都很不方便,因此“如何将方法的请求者与实现者解耦?”变得很重要,命令模式就能很好地解决这个问题。
eg1:在现实生活中,命令模式的例子也很多。比如看电视时,我们只需要轻轻一按遥控器就能完成频道的切换,这就是命令模式,将换台请求和换台处理完全解耦了。电视机遥控器(命令发送者)通过按钮(具体命令)来遥控电视机(命令接收者)。
eg2:再比如,我们去餐厅吃饭,菜单不是等到客人来了之后才定制的,而是已经预先配置好的。这样,客人来了就只需要点菜,而不是任由客人临时定制。餐厅提供的菜单就相当于把请求和处理进行了解耦,这就是命令模式的体现。
1.命令模式
命令(Command)模式,将一个请求封装为一个对象,使发出请求的责任和执行请求的责任分割开。这样两者之间通过命令对象进行沟通,这样方便将命令对象进行储存、传递、调用、增加与管理。
(其实可以看作是控制反转的一种形式,面向接口变成)
2.命令模式中的角色
组成(角色) | 作用 |
---|---|
抽象命令类(Command)角色 | 声明执行命令的接口,拥有执行命令的抽象方法 execute()。 |
具体命令类(Concrete Command)角色 | 是抽象命令类的具体实现类,它拥有接收者对象,并通过调用接收者的功能来完成命令要执行的操作。 |
实现者/接收者(Receiver)角色 | 执行命令功能的相关操作,是具体命令对象业务的真正实现者。 |
调用者/请求者(Invoker)角色 | 是请求的发送者,它通常拥有很多的命令对象,并通过访问命令对象来执行相关请求,它不直接访问接收者。 |
结构图:
命令模式的实现代码如下:
package command;
public class CommandPattern {
public static void main(String[] args) {
Command cmd = new ConcreteCommand();
Invoker ir = new Invoker(cmd);
System.out.println("客户访问调用者的call()方法...");
ir.call();
}
}
//调用者
class Invoker {
private Command command;
public Invoker(Command command) {
this.command = command;
}
public void setCommand(Command command) {
this.command = command;
}
public void call() {
System.out.println("调用者执行命令command...");
command.execute();
}
}
//抽象命令
interface Command {
public abstract void execute();
}
//具体命令
class ConcreteCommand implements Command {
private Receiver receiver;
ConcreteCommand() {
receiver = new Receiver();
}
public void execute() {
receiver.action();
}
}
//接收者
class Receiver {
public void action() {
System.out.println("接收者的action()方法被调用...");
}
}
运行结果:
客户访问调用者的call()方法...
调用者执行命令command...
接收者的action()方法被调用...
3.命令模式优缺点、使用场景
优点:
- 1.通过引入中间件(抽象接口)降低系统的耦合度。
- 2.扩展性良好,增加或删除命令非常方便。采用命令模式增加与删除命令不会影响其他类,且满足“开闭原则”
- 3.可以实现宏命令。命令模式可以与组合模式结合,将多个命令装配成一个组合命令,即宏命令。
- 4.方便实现 Undo 和 Redo 操作。命令模式可以与后面介绍的备忘录模式结合,实现命令的撤销与恢复。
- 5.可以在现有命令的基础上,增加额外功能。比如日志记录,结合装饰器模式会更加灵活。
缺点:
- 1.可能产生大量具体的命令类。因为每一个具体操作都需要设计一个具体命令类,这会增加系统的复杂性。
- 2.命令模式的结果其实就是接收方的执行结果,但是为了以命令的形式进行架构、解耦请求与实现,引入了额外类型结构(引入了请求方与抽象命令接口),增加了理解上的困难。不过这也是设计模式的通病,抽象必然会额外增加类的数量,代码抽离肯定比代码聚合更加难理解。
适用场景:
当系统的某项操作具备命令语义,且命令实现不稳定(变化)时,可以通过命令模式解耦请求与实现。使用抽象命令接口使请求方的代码架构稳定,封装接收方具体命令的实现细节。接收方与抽象命令呈现弱耦合(内部方法无需一致),具备良好的扩展性。
- 1.请求调用者需要与请求接收者解耦时,命令模式可以使调用者和接收者不直接交互。
- 2.系统随机请求命令或经常增加、删除命令时,命令模式可以方便地实现这些功能。
- 3.当系统需要执行一组操作时,命令模式可以定义宏命令来实现该功能。
- 4.当系统需要支持命令的撤销(Undo)操作和恢复(Redo)操作时,可以将命令对象存储起来,采用备忘录模式来实现。
参考文章:http://c.biancheng.net/view/1380.html