命令模式的两种不同实现

转载自命令模式（Command）的两种不同实现

命令模式（Command）：将一个请求封装成一个对象，使得你用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。

命令模式，顾名思义来理解即可，就是客户端发布一个命令（也就是“请求”），而这个命令是已经被封装成一个对象的。即这个命令对象的内部可能已经指定了该命令具体被谁负责执行。就像开发经理从客户那边获取对方的需求（命令），客户在描述具体的需求可以决定是否明确指出该需求的执行方。

命令模式的通用类图如下：

上图中，Invoker 类就相当于开发经理，ConcreteCommand 类是具体的命令，它继承自抽象命令类 Command 类，该抽象类中定义了每个命令被执行的方法 execute() 。Receiver 抽象类定义了对每一个具体的命令的执行方法 action() ,一旦接收到命令则立即行动。这里应该注意的是，每个具体的命令类都必须指定该命令的接收者，否则这命令发布了也没相应的人来完成，那就没戏了。

具体代码实现如下：

命令接收者相关类：

//抽象接收者，定义了每个接收者应该完成的业务逻辑
abstract class AbstractReceiver {
public abstract void doJob();
}
// 具体接收者01，实现自己真正的业务逻辑
class Receiver01 extends AbstractReceiver {
public void doJob() {
System.out.println("接收者01 完成工作 ...\n");
}
}
// 具体接收者02，实现自己真正的业务逻辑
class Receiver02 extends AbstractReceiver {
public void doJob() {
System.out.println("接收者02 完成工作 ...\n");
}
}

命令类：

// 抽象命令类，定义了每个具体命令被执行的入口方法execute()
abstract class AbstractCommand {
public abstract void execute();
}
// 具体命令类01，通过构造函数的参数决定了该命令由哪个接收者执行
class Command01 extends AbstsractCommand {
private AbstractReceiver receiver = null;
public Command01(AbstractReceiver receiver) {
this.receiver = receiver;
}
public void execute() {
System.out.println("命令01 被发布 ...");
this.receiver.doJob();
}
}
// 具体命令类02，通过构造函数的参数决定了该命令由哪个接收者执行
class Command02 extends AbstractCommand {
private AbstractReceiver receiver = null;
public Command02(AbstractReceiver receiver) {
this.receiver = receiver;
}
public void execute() {
System.out.println("命令02 被发布 ...");
this.receiver.doJob();
}
}

调用者类：

// 调用者，负责将具体的命令传送给具体的接收者
class Invoker {
private AbstractCommand command = null;
public void setCommand(AbstractCommand command) {
this.command = command;
}
public void action() {
this.command.execute();
}
}

测试类：

//测试类
public class Client {
public static void main(String[] args) {
// 创建调用者
Invoker invoker = new Invoker();
// 创建一个具体命令，并指定该命令被执行的具体接收者
AbstractCommand command01 = new Command01(new Receiver01());
// 给调用者发布一个具体命令
invoker.setCommand(command01);
// 调用者执行命令，其实是将其传送给具体的接收者并让其真正执行
invoker.action();
AbstractCommand command02 = new Command01(new Receiver02());
invoker.setCommand(command02);
invoker.action();
}
}

测试结果：

命令01 被发布 ...

接收者01 完成工作 ...

命令02 被发布 ...

接收者02 完成工作 ...

如上面测试中输出的结果，我们知道在客户端中每次声明并创建一个具体的命令对象时总要显式地将其指定给某一具体的接收者（也就是命令的最终执行者），这似乎不太灵活，在现实中有些命令的发布也确实不是预先就指定了该命令的接收者的。

我们可以修改一下类图，使得客户端在有必要的时候才显式地指明命令的接收者，如下：

较之第一个通用类图，这里的客户 Client 类不直接与接收者 Receiver 类相关，而仅仅与调用者 Invoker 类有联系，客户发布下来的一个命令或者请求，只需要到了调用者Invoker 这里就停止了，具体怎么实现，不必对客户公开，由调用者分配即可。这里的 Command 抽象类将子类中指定具体接收者的构造函数的逻辑提取出来，由具体子类提供通过调用父类构造函数的无参、有参构造函数来实现。主要修改的是命令相关的类。

具体逻辑请看下面的代码实现：

命令类：

/*
* 抽象命令类，使用构造函数的传入参数预先内定具体接收者，若想使用其他接收者，可在子类的构造函数中传入
*/
abstract class AbstractCommand {
protected AbstractReceiver receiver = null;
public AbstractCommand(AbstractReceiver receiver) {
this.receiver = receiver;
}
public abstract void execute();
}
// 具体命令类01，提供无参、有参两种构造函数
class Command01 extends AbstractCommand {
// 使用无参构造函数来默认使用的具体接收者
public Command01() {
super(new Receiver01());
}
// 使用有参构造函数来指定具体的接收者
public Command01(AbstractReceiver receiver) {
super(receiver);
}
public void execute() {
System.out.println("命令01 被发布 ...")
this.receiver.doJob();
}
}
// 具体命令类02，提供无参、有参两种构造函数
class Command02 extends AbstractCommand {
// 使用无参构造函数来默认使用的具体接收者
public Command02() {
super(new Receiver02());
}
// 使用有参构造函数来指定具体的接收者
public Command02(AbstractReceiver receiver) {
super(receiver);
}
public void execute() {
System.out.println("命令02 被发布 ...")
this.receiver.doJob();
}
}

修改后的测试类：

// 测试类
public class Client {
public static void main(String[] args) {
// 创建调用者
Invoker invoker = new Invoker();
// 创建一个具体命令，并指定该命令被执行的具体接收者
// AbstractCommand command01 = new Command01(new Receiver01());
AbstractCommand command01 = new Command01();
// 给调用者发布一个具体命令
invoker.setCommand(command01);
// 调用者执行命令，其实是将其传送给具体的接收者并让其真正执行
invoker.action();
// AbstractCommand command02 = new Command01(receiver02);
AbstractCommand command02 = new Command02();
invoker.setCommand(command02);
invoker.action();
System.out.println("\n设置命令01由接收者02执行...");
command01 = new Command01(new Receiver02());
invoker.setCommand(command01);
invoker.action();
}
}

测试结果：

命令01 被发布 ...

接收者01 完成工作 ...

命令02 被发布 ...

接收者02 完成工作 ...

设置命令01由接收者02执行...

命令01 被发布 ...

接收者02 完成工作 ...

此时在客户端中，我们不指明一个命令的具体接收者（执行者）也同样可以达到第一种实现方法中的效果。此外，客户也可以显式指出具体接收者，就像上面那样。

命令模式的优点：

1、调用者与接收者没有任何的依赖关系，它们时通过具体的命令的存在而存在的；

2、若有多个具体命令，只要扩展 Command 的子类即可，同样地具体接收者也可以相对应地进行扩展；

命令模式的缺点：其实上面优点中第2点在一定场景中也会变成缺点。如果具体的命令有很多个，那么子类就必然会暴增、膨胀。

但是，上面的具体代码实现中这种设计似乎也不太乐观，原因是每一个具体的命令都是由一个具体的接收者来执行的，在多交互的场景中这显然是太理想化的。于是，我想到了中介者模式（Mediator）中最主要的 Mediator 类中预先地注册了业务中需要交互的同事类的对象，接下来每一次交互逻辑都交给 Mediator 来“暗箱”操作。

根据上一段的想法，我们可以在抽象命令 Command 类中预先注册一定数量的具体接收者，那么具体命令中就可以决定是否要在多个接收者中进行协作完成了，这种协作的代码逻辑则应该写在覆盖父类的execute() 方法中，而在 execute() 方法中又可以运用模板方法模式（Template Method）进行设计。