标签：

  命令模式

转载请注明出处：http://blog.csdn.net/wei_chong_chong/article/details/51363736

１．概述：

　　在软件系统中，"行为请求者"与"行为实现者"通常呈现一种"紧耦合"。但在某些场合，比如要对行为进行"记录、撤销/重做、事务"等处理，这种无法抵御变化的紧耦合是不合适的。在这种情况下，如何将"行为请求者"与"行为实现者"解耦?将一组行为抽象为对象，实现二者之间的松耦合。这就是命令模式(Command Pattern)。

２．定义：

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

３．模式图：

命令模式结构和说明：

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

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

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

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

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

模式图示例代码：

４．代码分析：

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

/**
 * 命令接口，声明执行的操作
 */
public interface Command {
    /**
     * 执行命令对应的操作
     */
    public void execute();
}

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

/**
 * 具体的命令实现对象
 */
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();
    }
}

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

/**
 * 接收者对象
 */
public class Receiver {
    /**
     * 示意方法，真正执行命令相应的操作
     */
    public void action(){
       //真正执行命令操作的功能代码
    }
}

（4）接下来看看Invoker对象，示例代码如下： 

/**
 * 调用者
 */
public class Invoker {
    /**
     * 持有命令对象
     */
    private Command command = null;
    /**
     * 设置调用者持有的命令对象
     * @param command 命令对象
     */
    public void setCommand(Command command) {
       this.command = command;
    }
    /**
     * 示意方法，要求命令执行请求
     */
    public void runCommand() {
       //调用命令对象的执行方法
       command.execute();
    }
}

（5）再来看看Client的实现，注意这个不是我们通常意义上的测试客户端，主要功能是要创建命令对象并设定它的接收者，因此这里并没有调用执行的代码，示例代码如下： 

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.命令模式的关键在于引入了抽象命令接口，且发送者针对抽象命令接口编程，只有实现了抽象命令接口的具体命令才能与接收者相关联５

５．模式优缺点:

   5.1模式优点：

　　首先，命令模式的封装性很好：每个命令都被封装起来，对于客户端来说，需要什么功能就去调用相应的命令，而无需知道命令具体是怎么执行的。比如有一组文件操作的命令：新建文件、复制文件、删除文件。如果把这三个操作都封装成一个命令类，客户端只需要知道有这三个命令类即可，至于命令类中封装好的逻辑，客户端则无需知道。

　　其次，命令模式的扩展性很好，在命令模式中，在接收者类中一般会对操作进行最基本的封装，命令类则通过对这些基本的操作进行二次封装，当增加新命令的时候，对命令类的编写一般不是从零开始的，有大量的接收者类可供调用，也有大量的命令类可供调用，代码的复用性很好。比如，文件的操作中，我们需要增加一个剪切文件的命令，则只需要把复制文件和删除文件这两个命令组合一下就行了，非常方便。

总结一下就是如下几点：

　　1.降低对象之间的耦合度。

　　2.新的命令可以很容易地加入到系统中。

　　3.可以比较容易地设计一个组合命令。

　　4.调用同一方法实现不同的功能

   5.2模式缺点

　　使用命令模式可能会导致某些系统有过多的具体命令类。因为针对每一个命令都需要设计一个具体命令类，因此某些系统可能需要大量具体命令类，这将影响命令模式的使用

６．适用环境：

　　1.系统需要将请求调用者和请求接收者解耦，使得调用者和接收者不直接交互。

　　2.系统需要在不同的时间指定请求、将请求排队和执行请求。

　　3.系统需要支持命令的撤销(Undo)操作和恢复(Redo)操作。

4.系统需要将一组操作组合在一起，即支持宏命令。

７．相关模式比较：

（１）命令模式和组合模式

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

（2）命令模式与备忘录模式

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

（3）命令模式与模板方法模式

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

８．实例解析：

　　下面用一个例子来更深入的了解一下命令模式吧：电脑开机过程。

用户使用电脑只需点击开机按钮，电脑就自己打开了。

  当客户按下按钮的时候，按钮本身并不知道如何处理，于是通过连接线来请求主板，让主板去完成真正启动机器的功能。客户操作的始终是按钮，按钮后面的事情客户就统统不管了。
　　在命令模式中，会定义一个命令的接口，用来约束所有的命令对象，然后提供具体的命令实现，每个命令实现对象是对客户端某个请求的封装，对应于机箱上的按钮，一个机箱上可以有很多按钮，也就相当于会有多个具体的命令实现对象。
 　在命令模式中，命令对象并不知道如何处理命令，会有相应的接收者对象来真正执行命令。就像电脑的例子，机箱上的按钮并不知道如何处理功能，而是把这个请求转发给主板，由主板来执行真正的功能，这个主板就相当于命令模式的接收者。
　　在命令模式中，命令对象和接收者对象的关系，并不是与生俱来的，需要有一个装配的过程，命令模式中的Client对象就来实现这样的功能。这就相当于在电脑的例子中，有了机箱上的按钮，也有了主板，还需要有一个连接线把这个按钮连接到主板上才行。
　　命令模式还会提供一个Invoker对象来持有命令对象，就像电脑的例子，机箱上会有多个按钮，这个机箱就相当于命令模式的Invoker对象。这样一来，命令模式的客户端就可以通过Invoker来触发并要求执行相应的命令了，这也相当于真正的客户是按下机箱上的按钮来操作电脑一样。

（1）定义主板
　　根据前面的描述，我们会发现，真正执行客户命令或请求的是主板，也只有主板才知道如何去实现客户的命令，因此先来抽象主板，把它用对象描述出来。
  先来定义主板的接口，最起码主板会有一个能开机的方法，示例代码如下： 

/**
 * 主板的接口
 */
public interface MainBoardApi {
    /**
     * 主板具有能开机的功能
     */
    public void open();
}

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

/**
 * 技嘉主板类，开机命令的真正实现者，在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("机器已经正常打开，请操作");
    }
}

　　 微星主板的实现和这个完全一样，只是把技嘉改名成微星了。
（2）定义命令接口和命令的实现
  对于客户来说，开机就是按下按钮，别的什么都不想做。把用户的这个动作抽象一下，就相当于客户发出了一个命令或者请求，其它的客户就不关心了。为描述客户的命令，现定义出一个命令的接口，里面只有一个方法，那就是执行，示例代码如下： 

/**
 * 命令接口，声明执行的操作
 */
public interface Command {
    /**
     * 执行命令对应的操作
     */
    public void execute();
}

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

/**
 * 开机命令的实现，实现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();
    }
}

　 由于客户不想直接和主板打交道，而且客户根本不知道具体的主板是什么，客户只是希望按下启动按钮，电脑就正常启动了，就这么简单。就算换了主板，客户还是一样的按下启动按钮就可以了。
　　换句话说就是：客户想要和主板完全解耦，怎么办呢？
　　这就需要在客户和主板之间建立一个中间对象了，客户发出的命令传递给这个中间对象，然后由这个中间对象去找真正的执行者——主板，来完成工作。
　　很显然，这个中间对象就是上面的命令实现对象，请注意：这个实现其实是个虚的实现，真正的实现是主板完成的，在这个虚的实现里面，是通过转调主板的功能来实现的，主板对象实例，是从外面传进来的。

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

/**
 * 机箱对象，本身有按钮，持有按钮对应的命令对象
 */
public class Box {
    /**
     * 开机命令对象
     */
    private Command openCommand;
    /**
     * 设置开机命令对象
     * @param command 开机命令对象
     */
    public void setOpenCommand(Command command){
       this.openCommand = command;
    }
    /**
     * 提供给客户使用，接收并响应用户请求，相当于按钮被按下触发的方法
     */
    public void openButtonPressed(){
       //按下按钮，执行命令
       openCommand.execute();
    }
}

（4）客户使用按钮
　　抽象好了机箱和主板，命令对象也准备好了，客户想要使用按钮来完成开机的功能，在使用之前，客户的第一件事情就应该是把按钮和主板组装起来，形成一个完整的机器。
　　在实际生活中，是由装机工程师来完成这部分工作，这里为了测试简单，直接写在客户端开头了。机器组装好过后，客户应该把与主板连接好的按钮对象放置到机箱上，等待客户随时操作。把这个过程也用代码描述出来，示例代码如下： 

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();
    }
}

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

技嘉主板现在正在开机，请等候
接通电源......
设备检查......
装载系统......
机器正常运转起来......
机器已经正常打开，请操作

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

 ７．总结

　　对于一个场合到底用不用模式，这对所有的开发人员来说都是一个很纠结的问题。有时候，因为预见到需求上会发生的某些变化，为了系统的灵活性和可扩展性而使用了某种设计模式，但这个预见的需求偏偏没有，相反，没预见到的需求倒是来了不少，导致在修改代码的时候，使用的设计模式反而起了相反的作用，以至于整个项目组怨声载道。这样的例子，我相信每个程序设计者都遇到过。所以，基于敏捷开发的原则，我们在设计程序的时候，如果按照目前的需求，不使用某种模式也能很好地解决，那么我们就不要引入它，因为要引入一种设计模式并不困难，我们大可以在真正需要用到的时候再对系统进行一下，引入这个设计模式。拿命令模式来说吧，我们开发中，请求-响应模式的功能非常常见，一般来说，我们会把对请求的响应操作封装到一个方法中，这个封装的方法可以称之为命令，但不是命令模式。到底要不要把这种设计上升到模式的高度就要另行考虑了，因为，如果使用命令模式，就要引入调用者、接收者两个角色，原本放在一处的逻辑分散到了三个类中，设计时，必须考虑这样的代价是否值得。

命令模式

标签：

原文地址：http://blog.csdn.net/wei_chong_chong/article/details/51363736