再说设计模式-命令模式

定义

命令模式是一个高内聚的模式，其定义如下：

Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.
将一个请求封装成一个对象，从而让你使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。

命令模式的通用类图为：

命令模式的通用类图

在该类图中，我们看到三个角色：

• Receive接收者角色
  该角色就是干活的角色，命令传递到这里被执行；
• Command命令角色
  需要执行的所有命令都在这里声明；
• Invoker调用者角色
  接收到命令，并执行命令。

命令模式比较简单，但是在项目中非常频繁地使用，因为它的封装性非常好，把请求方(Invoker)和执行方(Receiver)分开了，扩展性也有很好的保障，能用代码比较简单。

通用Receiver类

public abstract class Receiver {
  // 抽象接收者， 定义每个接收者者必须完成的业务
  public abstract void doSomething();
}

具体的Receiver类

public class ConcreteReceiver1 extends Receiver {
  public void doSomething() {
    // do something
  }
}

public class ConcreteReceiver2 extends Receiver {
  public void doSomething() {
    // do something
  }
}

接收者可以是N个，这要依赖业务的具体定义。命令角色是命令模式的核心，其抽象的命令代码如下：

public abstract class Command {
  // 每个命令类都必须有一个执行命令的方法
  public abstract void execute();
}

根据环境的需求，具体的命令类也可以有N个，其实现类如下：

public class ConcreteCommand1 extends Command {
  // 对哪个Receiver类进行命令处理
  private Receiver receiver;
  public ConcreteCommand1(Receiver receiver) {
    this.receiver = receiver;
  }
  // 必须实现一个命令
  public void execute() {
    // do something...
    // 业务处理
    this.receiver.doSomething();
  }
}

public class ConcreteCommand2 extends Command {
  // 对哪个Receiver类进行命令处理
  private Receiver receiver;
  public ConcreteCommand2(Receiver receiver) {
    this.receiver = receiver;
  }
  // 必须实现一个命令
  public void execute() {
    // do something...
    // 业务处理
    this.receiver.doSomething();
  }
}

这里定义了两个具体的命令类，读者可以在实际应用中扩展该命令类。在每个命令类中，通过构造函数定义了该命令是针对哪一个接收者发出的，定义一个命令接收的主体。

调用者Invoker类：

public class Invoker {
  private Command command;
  // 接受命令
  public void setCommand(Command _command) {
    this.command = _command;
  }

  // 执行命令
  public void action() {
    this.command.execute();
  }
}

调用者就像是一个受气包，不管什么命令，都要接收、执行！

场景类如下：

public class Client {
  public static void main(String[] args) {
    // 首先声明调用者Invoker
    Invoker invoker = new Invoker();
    // 定义接收者
    Receiver receiver = new ConcreteReciver1();
    // 定义一个发送给接收者的命令
    Command command = new ConcreteCommand1(receiver);
    // 把命令交给调用者执行
    invoker.setCommand(command);
    invoker.action();
  }
}

优点

• 类间解耦
  调用者角色与接收者角色之间没有任何依赖关系，调用者实现功能时只须调用Command抽象类的execute方法就可以，不需要关心到底是哪个接收者执行；
• 可扩展性
  Command的子类可以非常容易扩展，而调用者Invoker和高层的模块Client不产生严重的代码耦合；
• 命令模式结合 其他模式更优秀
  命令模式可以结合责任链模式，实现命令族解析任务；结合模板方法模式，则可以减少Command子类的膨胀问题。

缺点

命令模式也是有缺点的，请看Command的子类：如果有N个命令，问题就出来了，Command的子类就可不是几个，而是N个，这个类膨胀得非常大，这个就需要我们在项目中慎重考虑使用。

使用场景

只要你认为是命令的地方就可以采用命令模式，例如，在GUI开发中，一个按钮的点击是一个命令，可以采用命令模式；模拟DOS命令的时候，当然也要采用命令模式；触发——反馈机制的处理等；