13.2　解 决 方 案

13.2.1　使用命令模式来解决问题

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

1．命令模式的定义

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

2．应用命令模式来解决问题的思路

下面来看看实际电脑的解决方案。

先画个图来描述一下，看看实际的电脑是如何处理上面描述的这个问题的，如图13.1所示。

图13.1　电脑操作示意图

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

这里为了描述它们之间的关系，把主板画到了机箱的外面。如果连接线连接到不同的主板，那么真正执行按钮请求的主板也就不同了，而客户是不知道这些变化的。

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

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

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

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

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

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

13.2.2　命令模式的结构和说明

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

图13.2　命令模式的结构图

■　Command：定义命令的接口，声明执行的方法。

■　ConcreteCommand：命令接口实现对象，是“虚”的实现；通常会持有接收者，并调用接收者的功能来完成命令要执行的操作。

■　Receiver：接收者，真正执行命令的对象。任何类都可能成为一个接收者，只要它能够实现命令要求实现的相应功能。

■　Invoker：要求命令对象执行请求，通常会持有命令对象，可以持有很多的命令对象。这个是客户端真正触发命令并要求命令执行相应操作的地方，也就是说相当于使用命令对象的入口。

■　Client：创建具体的命令对象，并且设置命令对象的接收者。注意这个不是我们常规意义上的客户端，而是在组装命令对象和接收者，或许，把这个Client称为装配者会更好理解，因为真正使用命令的客户端是从Invoker来触发执行。

13.2.3　命令模式示例代码

（1）先来看看命令接口的定义。示例代码如下：

（2）接下来看看具体的命令实现对象。示例代码如下：

（3）再来看看接收者对象的实现示意。示例代码如下：

（4）下面来看看Invoker对象。示例代码如下：

（5）再来看看Client的实现。

注意

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

示例代码如下：

13.2.4　使用命令模式来实现示例

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

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

■　机箱相当于是Invoker。

■　主板相当于接收者对象。

■　命令对象持有一个接收者对象，就相当于是给机箱的按钮连上了一根连接线。

■　当机箱上的按钮被按下的时候，机箱就把这个命令通过连接线发送出去。

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

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

图13.3　使用命令模式来实现示例的结构示意图

还是来看看示例代码，会比较清楚。

1．定义主板

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

先来定义主板的接口，最起码主板会有一个能开机的方法。示例代码如下：

定义了接口，那就接着定义实现类吧，定义两个主板的实现类，一个是技嘉主板，一个是微星主板，现在的实现是一样的，但是不同的主板对同一个命令的操作可以是不同的，这点大家要注意。由于两个实现基本一样，就示例一个。示例代码如下：

微星主板的实现和这个完全一样，只是把技嘉改名成微星即可。

2．定义命令接口和命令的实现

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

有了命令的接口，再来定义一个具体的实现，其实就是模拟现实中机箱上按钮的功能。因为我们按下的是按钮，但是按钮本身是不知道如何启动电脑的，它需要把这个命令转给主板，让主板去真正地执行开机功能。示例代码如下：

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

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

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

很显然，这个中间对象就是上面的命令实现对象。

注意

这个实现其实是个虚的实现，真正的实现是主板完成的，在这个虚的实现里面，是通过转调主板的功能来实现的，主板对象实例，是从外面传进来的。

3．提供机箱

客户需要操作按钮，按钮是放置在机箱之上的，所以需要把机箱也定义出来。示例代码如下：

4．客户使用按钮

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

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

运行一下，看看效果。输出如下：

你可以给命令对象组装不同的主板实现类，然后再次测试，看看效果。

事实上，你会发现，如果对象结构已经组装好了以后，对于真正的客户端，也就是真实的用户而言，任务就是面对机箱，按下机箱上的按钮就可以执行开机的命令了，实际生活中也是这样的。

5．小结

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

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

提示

在模式讲解的时候会给大家一个参数化配置的示例，这里就不多讲了。至于对请求排队或记录请求日志，以及支持可撤销的操作等功能，也放到模式讲解一节里面。