湫枫染墨

行为型-命令模式(Command)

4/5/2022 设计模式

摘要

JDK：1.8.0_202

# 一：场景问题

# 1.1 电脑开机

电脑启动过程主要有这么几个步骤：首先加载电源，然后是设备检查，再然后是装载系统，最后电脑就正常启动了。可是谁来完成这些过程？如何完成？

不能让使用电脑的客户——就是我们来做这些工作吧，真正完成这些工作的是主板，那么客户和主板如何发生联系呢？现实中，是用连接线把按钮连接到主板上的，这样当客户按下按钮的时候，就相当于发命令给主板，让主板去完成后续的工作。

另外，从客户的角度来看，开机就是按下按钮，不管什么样的主板都是一样的，也就是说，客户只管发出命令，谁接收命令，谁实现命令，如何实现，客户是不关心的。

把上面的问题抽象描述一下：客户端只是想要发出命令或者请求，不关心请求的真正接收者是谁，也不关心具体如何实现，而且同一个请求的动作可以有不同的请求内容，当然具体的处理功能也不一样，请问该怎么实现？

# 二：解决方案

用来解决上述问题的一个合理的解决方案就是命令模式。

命令模式：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。

# 2.1 解决思路

当客户按下按钮的时候，按钮本身并不知道如何处理，于是通过连接线来请求主板，让主板去完成真正启动机器的功能。

通过引入按钮和连接线，来让发出命令的客户和命令的真正实现者——主板完全解耦，客户操作的始终是按钮，按钮后面的事情客户就统统不管了。

要用程序来解决上面提出的问题，一种自然的方案就是来模拟上述解决思路。

  1. 在命令模式中，会定义一个命令的接口，用来约束所有的命令对象，然后提供具体的命令实现，每个命令实现对象是对客户端某个请求的封装，对应于机箱上的按钮，一个机箱上可以有很多按钮，也就相当于会有多个具体的命令实现对象。

  2. 在命令模式中，命令对象并不知道如何处理命令，会有相应的接收者对象来真正执行命令。就像电脑的例子，机箱上的按钮并不知道如何处理功能，而是把这个请求转发给主板，由主板来执行真正的功能，这个主板就相当于命令模式的接收者。

  3. 在命令模式中，命令对象和接收者对象的关系，并不是与生俱来的，需要有一个装配的过程，命令模式中的Client对象就来实现这样的功能。这就相当于在电脑的例子中，有了机箱上的按钮，也有了主板，还需要有一个连接线把这个按钮连接到主板上才行。

  4. 命令模式还会提供一个Invoker对象来持有命令对象，就像电脑的例子，机箱上会有多个按钮，这个机箱就相当于命令模式的Invoker对象。这样一来，命令模式的客户端就可以通过Invoker来触发并要求执行相应的命令了，这也相当于真正的客户是按下机箱上的按钮来操作电脑一样。

# 2.2 模式结构和说明

命令模式的结构如图所示：

classDiagram Command <--o Invoker Command <|.. ConcreteCommand Receiver <--o ConcreteCommand Receiver <.. Client ConcreteCommand <.. Client class Command{ <<interface>> +execute()* void } class Invoker{ -Command command +runCommand() void } class ConcreteCommand{ -Receiver receiver -String state +ConcreteCommand(Receiver) +execute() void } class Receiver { +action() void }
  • Command：定义命令的接口，声明执行的方法。
  • ConcreteCommand：命令接口实现对象，是 "虚" 的实现；通常会持有接收者，并调用接收者的功能来完成命令要执行的操作。
  • Receiver：接收者，真正执行命令的对象。任何类都可能成为一个接收者，只要它能够实现命令要求实现的相应功能。
  • Invoker：要求命令对象执行请求，通常会持有命令对象，可以持有很多的命令对象。这个是客户端真正触发命令并要求命令执行相应操作的地方，也就是说相当于使用命令对象的入口。
  • Client：创建具体的命令对象，并且设置命令对象的接收者。注意这个不是我们常规意义上的客户端，而是在组装命令对象和接收者，或许，把这个Client称为装配者会更好理解，因为真正使用命令的客户端是从Invoker来触发执行。

# 2.3 示例代码

接收者对象的实现：

/**
 * 接收者对象
 */
public class Receiver {

    /**
     * 示意方法，真正执行命令相应的操作
     */
    public void action() {
        //真正执行命令操作的功能代码
    }
}
1
2
3
4
5
6
7
8
9
10
11
12

命令接口的定义：

/**
 * 命令接口，声明执行的操作
 */
public interface Command {

    /**
     * 执行命令对应的操作
     */
    void execute();
}
1
2
3
4
5
6
7
8
9
10

具体的命令实现对象：

/**
 * 具体的命令实现对象
 */
public class ConcreteCommand implements Command {

    /**
     * 持有相应的接收者对象
     */
    private Receiver receiver = null;

    /**
     * 示意，命令对象可以有自己的状态
     */
    private String state;

    /**
     * 构造方法，传入相应的接收者对象
     *
     * @param receiver 相应的接收者对象
     */
    public ConcreteCommand(Receiver receiver) {
        this.receiver = receiver;
    }

    public void execute() {
        //通常会转调接收者对象的相应方法，让接收者来真正执行功能
        receiver.action();
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

Invoker对象：

/**
 * 调用者
 */
public class Invoker {

    /**
     * 持有命令对象
     */
    private Command command = null;

    /**
     * 设置调用者持有的命令对象
     *
     * @param command 命令对象
     */
    public void setCommand(Command command) {
        this.command = command;
    }

    /**
     * 示意方法，要求命令执行请求
     */
    public void runCommand() {
        //调用命令对象的执行方法
        command.execute();
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

客户端，注意这个不是我们通常意义上的测试客户端，主要功能是要创建命令对象并设定它的接收者，因此这里并没有调用执行的代码：

public class Client {
    /**
     * 示意，负责创建命令对象，并设定它的接收者
     */
    public void assemble() {
        //创建接收者
        Receiver receiver = new Receiver();
        //创建命令对象，设定它的接收者
        Command command = new ConcreteCommand(receiver);
        //创建Invoker，把命令对象设置进去
        Invoker invoker = new Invoker();
        invoker.setCommand(command);
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14

# 2.4 实现案例

要使用命令模式来实现示例，需要先把命令模式中所涉及的各个部分，在实际的示例中对应出来，然后才能按照命令模式的结构来设计和实现程序。根据前面描述的解决思路，大致对应如下：

机箱上的按钮就相当于是命令对象

机箱相当于是Invoker

主板相当于接收者对象

命令对象持有一个接收者对象，就相当于是给机箱的按钮连上了一根连接线，当机箱上的按钮被按下的时候，机箱就把这个命令通过连接线发送出去。

主板类才是真正实现开机功能的地方，是真正执行命令的地方，也就是 "接收者"。命令的实现对象，其实是个"虚"的实现，就如同那根连接线，它哪知道如何实现啊，还不就是把命令传递给连接线连到的主板。

使用命令模式来实现示例的结构如图所示：

classDiagram Command <--o Box Command <|.. OpenCommand MainBoardApi <--o OpenCommand MainBoardApi <|.. GigaMainBoard MainBoardApi <|.. MsiMainBoard MainBoardApi <.. Client OpenCommand <.. Client class Command{ <<interface>> +execute()* void } class Box{ -Command openCommand +openButtonPressed() void } class OpenCommand{ -MainBoardApi mainBoard +openButtonPressed(MainBoardApi) +execute() void } class MainBoardApi { <<interface>> +open()* void } class GigaMainBoard { +open() void } class MsiMainBoard { +open() void }

定义主板：

根据前面的描述，会发现，真正执行客户命令或请求的是主板，也只有主板才知道如何去实现客户的命令，因此先来抽象主板，把它用对象描述出来。

/**
 * 主板的接口
 */
public interface MainBoardApi {
    /**
     * 主板具有能开机的功能
     */
    public void open();
}
1
2
3
4
5
6
7
8
9

主板接口的实现类：(GigaMainBoard.java 和 MsiMainBoard.java)

/**
 * 技嘉主板类，开机命令的真正实现者，在Command模式中充当Receiver
 */
public class GigaMainBoard implements MainBoardApi {
    /**
     * 真正的开机命令的实现
     */
    public void open() {
        System.out.println("技嘉主板现在正在开机，请等候");
        System.out.println("接通电源......");
        System.out.println("设备检查......");
        System.out.println("装载系统......");
        System.out.println("机器正常运转起来......");
        System.out.println("机器已经正常打开，请操作");
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
/**
 * 微星主板类，开机命令的真正实现者，在Command模式中充当Receiver
 */
public class MsiMainBoard implements MainBoardApi {
    /**
     * 真正的开机命令的实现
     */
    public void open() {
        System.out.println("微星主板现在正在开机，请等候");
        System.out.println("接通电源......");
        System.out.println("设备检查......");
        System.out.println("装载系统......");
        System.out.println("机器正常运转起来......");
        System.out.println("机器已经正常打开，请操作");
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

定义命令接口：

对于客户来说，开机就是按下按钮，别的什么都不想做。把用户的这个动作抽象一下，就相当于客户发出了一个命令或者请求，其它的客户就不关心了。为描述客户的命令，现定义出一个命令的接口，里面只有一个方法，那就是执行

/**
 * 命令接口，声明执行的操作
 */
public interface Command {
    /**
     * 执行命令对应的操作
     */
    public void execute();
}
1
2
3
4
5
6
7
8
9

命令接口的具体实现：

/**
 * 开机命令的实现，实现Command接口，
 * 持有开机命令的真正实现，通过调用接收者的方法来实现命令
 */
public class OpenCommand implements Command {
    /**
     * 持有真正实现命令的接收者——主板对象
     */
    private MainBoardApi mainBoard = null;

    /**
     * 构造方法，传入主板对象
     *
     * @param mainBoard 主板对象
     */
    public OpenCommand(MainBoardApi mainBoard) {
        this.mainBoard = mainBoard;
    }

    public void execute() {
        //对于命令对象，根本不知道如何开机，会转调主板对象
        //让主板去完成开机的功能
        this.mainBoard.open();
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

由于客户不想直接和主板打交道，而且客户根本不知道具体的主板是什么，客户只是希望按下启动按钮，电脑就正常启动了，就这么简单。就算换了主板，客户还是一样的按下启动按钮就可以了。

换句话说就是：客户想要和主板完全解耦，怎么办呢？

这就需要在客户和主板之间建立一个中间对象了，客户发出的命令传递给这个中间对象，然后由这个中间对象去找真正的执行者——主板，来完成工作。

很显然，这个中间对象就是上面的命令实现对象，请注意：这个实现其实是个虚的实现，真正的实现是主板完成的，在这个虚的实现里面，是通过转调主板的功能来实现的，主板对象实例，是从外面传进来的。

机箱：

/**
 * 机箱对象，本身有按钮，持有按钮对应的命令对象
 */
public class Box {
    /**
     * 开机命令对象
     */
    private Command openCommand;

    /**
     * 设置开机命令对象
     *
     * @param command 开机命令对象
     */
    public void setOpenCommand(Command command) {
        this.openCommand = command;
    }

    /**
     * 提供给客户使用，接收并响应用户请求，相当于按钮被按下触发的方法
     */
    public void openButtonPressed() {
        //按下按钮，执行命令
        openCommand.execute();
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

客户使用的按钮：

抽象好了机箱和主板，命令对象也准备好了，客户想要使用按钮来完成开机的功能，在使用之前，客户的第一件事情就应该是把按钮和主板组装起来，形成一个完整的机器。

在实际生活中，是由装机工程师来完成这部分工作，这里为了测试简单，直接写在客户端开头了。机器组装好过后，客户应该把与主板连接好的按钮对象放置到机箱上，等待客户随时操作。把这个过程也用代码描述出来，示例代码如下：

public class Client {
    public static void main(String[] args) {
        //1：把命令和真正的实现组合起来，相当于在组装机器，
        //把机箱上按钮的连接线插接到主板上。
        MainBoardApi mainBoard = new GigaMainBoard();
        OpenCommand openCommand = new OpenCommand(mainBoard);
        //2：为机箱上的按钮设置对应的命令，让按钮知道该干什么
        Box box = new Box();
        box.setOpenCommand(openCommand);

        //3：然后模拟按下机箱上的按钮
        box.openButtonPressed();
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14

# 2.5 小结

如同前面的示例，把客户的开机请求封装成为一个OpenCommand对象，客户的开机操作就变成了执行OpenCommand对象的方法了？如果还有其它的命令对象，比如让机器重启的ResetCommand对象；那么客户按下按钮的动作，就可以用这不同的命令对象去匹配，也就是对客户进行参数化。

用大白话描述就是：客户按下一个按钮，到底是开机还是重启，那要看参数化配置的是哪一个具体的按钮对象，如果参数化的是开机的命令对象，那就执行开机的功能，如果参数化的是重启的命令对象，那就执行重启的功能。虽然按下的是同一个按钮，但是请求是不同的，对应执行的功能也就不同了。

# 三：模式讲解

# 3.1 认识命令模式

1. 命令模式的关键

命令模式的关键之处就是把请求封装成为对象，也就是命令对象，并定义了统一的执行操作的接口，这个命令对象可以被存储、转发、记录、处理、撤销等，整个命令模式都是围绕这个对象在进行。

2. 命令模式的组装和调用

在命令模式中经常会有一个命令的组装者，用它来维护命令的 "虚" 实现和真实实现之间的关系。如果是超级智能的命令，也就是说命令对象自己完全实现好了，不需要接收者，那就是命令模式的退化，不需要接收者，自然也不需要组装者了。

而真正的用户就是具体化请求的内容，然后提交请求进行触发就好了。真正的用户会通过invoker来触发命令。

在实际开发过程中，Client和Invoker可以融合在一起，由客户在使用命令模式的时候，先进行命令对象和接收者的组装，组装完成后，就可以调用命令执行请求。

3. 命令模式的接收者

接收者可以是任意的类，对它没有什么特殊要求，这个对象知道如何真正执行命令的操作，执行时是从command的实现类里面转调过来。

一个接收者对象可以处理多个命令，接收者和命令之间没有约定的对应关系。接收者提供的方法个数、名称、功能和命令中的可以不一样，只要能够通过调用接收者的方法来实现命令对应的功能就可以了。

4. 智能命令

在标准的命令模式里面，命令的实现类是没有真正实现命令要求的功能的，真正执行命令的功能的是接收者。

如果命令的实现对象比较智能，它自己就能真实地实现命令要求的功能，而不再需要调用接收者，那么这种情况就称为智能命令。

也可以有半智能的命令，命令对象知道部分实现，其它的还是需要调用接收者来完成，也就是说命令的功能由命令对象和接收者共同来完成。

5. 发起请求的对象和真正实现的对象是解耦的

请求究竟由谁处理，如何处理，发起请求的对象是不知道的，也就是发起请求的对象和真正实现的对象是解耦的。发起请求的对象只管发出命令，其它的就不管了。

# 3.2 优缺点

1. 更松散的耦合

命令模式使得发起命令的对象——客户端，和具体实现命令的对象——接收者对象完全解耦，也就是说发起命令的对象，完全不知道具体实现对象是谁，也不知道如何实现。

2. 更动态的控制

命令模式把请求封装起来，可以动态对它进行参数化、队列化和日志化等操作，从而使得系统更灵活。

3. 能很自然的复合命令

命令模式中的命令对象，能够很容易的组合成为复合命令，就是前面讲的宏命令，从而使系统操作更简单，功能更强大。

4. 更好的扩展性

由于发起命令的对象和具体的实现完全解耦，因此扩展新的命令就很容易，只需要实现新的命令对象，然后在装配的时候，把具体的实现对象设置到命令对象里面，然后就可以使用这个命令对象，已有的实现完全不用变化。

# 3.3. 思考命令模式

1. 命令模式的本质

命令模式的本质：封装请求。

前面讲了，命令模式的关键就是把请求封装成为命令对象，然后就可以对这个对象进行一系列的处理了，比如上面讲到的参数化配置、可撤销操作、宏命令、队列请求、日志请求等功能处理。

  1. 何时选用命令模式

建议在如下情况中，选用命令模式：

如果需要抽象出需要执行的动作，并参数化这些对象，可以选用命令模式，把这些需要执行的动作抽象成为命令，然后实现命令的参数化配置

如果需要在不同的时刻指定、排列和执行请求，可以选用命令模式，把这些请求封装成为命令对象，然后实现把请求队列化

如果需要支持取消操作，可以选用命令模式，通过管理命令对象，能很容易的实现命令的恢复和重做的功能

如果需要支持当系统崩溃时，能把对系统的操作功能重新执行一遍，可以选用命令模式，把这些操作功能的请求封装成命令对象，然后实现日志命令，就可以在系统恢复回来后，通过日志获取命令列表，从而重新执行一遍功能

在需要事务的系统中，可以选用命令模式，命令模式提供了对事务进行建模的方法，命令模式有一个别名就是Transaction。

# 3.4 相关模式

1. 命令模式和组合模式

这两个模式可以组合使用。

在命令模式中，实现宏命令的功能，就可以使用组合模式来实现。前面的示例并没有按照组合模式来做，那是为了保持示例的简单，还有突出命令模式的实现，这点请注意。

2. 命令模式和备忘录模式

这两个模式可以组合使用。

在命令模式中，实现可撤销操作功能时，前面讲了有两种实现方式，其中有一种就是保存命令执行前的状态，撤销的时候就把状态恢复回去。如果采用这种方式实现，就可以考虑使用备忘录模式。

如果状态存储在命令对象里面，那么还可以使用原型模式，把命令对象当作原型来克隆一个新的对象，然后把克隆出来的对象通过备忘录模式存放。

3. 命令模式和模板方法模式

这两个模式从某种意义上有相似的功能，命令模式可以作为模板方法的一种替代模式，也就是说命令模式可以模仿实现模板方法模式的功能。

如同前面讲述的退化的命令模式可以实现Java的回调，而Invoker智能化后向服务进化，如果Invoker的方法就是一个算法骨架，其中有两步在这个骨架里面没有具体实现，需要外部来实现，这个时候就可以通过回调命令接口来实现。

而类似的功能在模板方法里面，一个算法骨架，其中有两步在这个骨架里面没有具体实现，是先调用抽象方法，然后等待子类来实现。

可以看出虽然实现方式不一样，但是可以实现相同的功能。

# 四：JDK

# 五：参考文献

最后更新: 5/17/2022, 3:10:12 PM

行为型-观察者模式(Observer)