【设计模式】第二十一章:命令模式详解及应用案例

系列文章

【设计模式】七大设计原则
【设计模式】第一章:单例模式
【设计模式】第二章:工厂模式
【设计模式】第三章:建造者模式
【设计模式】第四章:原型模式
【设计模式】第五章:适配器模式
【设计模式】第六章:装饰器模式
【设计模式】第七章:代理模式
【设计模式】第八章:桥接模式
【设计模式】第九章:外观模式 / 门面模式
【设计模式】第十章:组合模式
【设计模式】第十一章:享元模式
【设计模式】第十二章:观察者模式
【设计模式】第十三章:模板方法模式
【设计模式】第十四章:策略模式
【设计模式】第十五章:责任链模式
【设计模式】第十六章:迭代器模式
【设计模式】第十七章:状态模式
【设计模式】第十八章:备忘录模式
【设计模式】第十九章:访问者模式
【设计模式】第二十章:解释器模式
【设计模式】第二十一章:命令模式
【设计模式】第二十二章:中介者模式



命令模式

一、定义

摘自百度百科: 在软件系统中,“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。但在某些场合,比如要对行为进行“记录、撤销/重做、事务”等处理,这种无法抵御变化的紧耦合是不合适的。在这种情况下,如何将“行为请求者”与“行为实现者”解耦?将一组行为抽象为对象实现二者之间的松耦合。这就是命令模式(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)操作,也可以考虑使用命令模式,见命令模式的扩展。


五、优缺点

优点

  1. 降低了系统耦合度。
  2. 新的命令可以很容易添加到系统中去。

缺点

使用命令模式可能会导致某些系统有过多的具体命令类。


推荐

关注博客和公众号获取最新文章

Bummon’s BlogBummon’s Home公众号

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Bummon.

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值