设计模式-第十五篇命令模式

1. 定义

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

2. 通用类图

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

• Receiver接受者角色

   该角色就是干活的角色，命令传递到这里是应该被执行的，具体到我们上面的例子中就是Group的三个实现类。

• Command命令角色

   需要执行的所有命令都在这里声明

• Invoker调用者角色

   接收到命令，并执行命令。

3. 代码实现 

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

 通用Receiver类

package CommandPattern;

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

    很奇怪，为什么Receiver是一个抽象类？那是因为接受者可以有多个，有多个就需要定义一个所有特性的抽象集合-抽象的接受者，其具体的接受者如下所示：

package CommandPattern;

public class ConcreteReceiver1 extends Receiver{
    //每个接受者都必须处理一定的业务逻辑
    public void doSomething()
    {

    }
}

package CommandPattern;

public class ConcreteReceiver2 extends Receiver{
    //每个接受者都必须处理一定的业务逻辑
    public void doSomething()
    {

    }
}

      接受者可以有N个，这要依赖业务的具体含义。命令角色是命令模式的核心，其抽象的命令类如下一样：

package CommandPattern;

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

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

package CommandPattern;

public class ConcreteCommand1 extends Command{
    //对哪个Receiver类进行命令处理
    private Receiver receiver;
    //构造函数传递接受者
    public ConcreteCommand1(Receiver _receiver)
    {
        this.receiver=_receiver;
    }
    //必须实现一个命令
    public void execute()
    {
        this.receiver.doSomething();
    }
}

package CommandPattern;

public class ConcreteCommand2 extends Command{
    //对哪个Receiver类进行命令处理
    private Receiver receiver;
    //构造函数传递接受者
    public ConcreteCommand2(Receiver _receiver)
    {
        this.receiver=_receiver;
    }
    //必须实现一个命令
    public void execute()
    {
        this.receiver.doSomething();
    }
}

     定义了两个具体的命令类，读者可以在实际应用中扩展该命令类。在每个命令类中，通过构造函数定义了该命令是针对哪一个接受者发出的，定义一个命令接收的主体。调用者非常简单，仅实现命令的传递。

     调用者Invoker类

package CommandPattern;

public class Invoker {
    private Command command;
    //接收包，接收命令
    public void setCommand(Command _command) {
        this.command = _command;
    }
    //接收命令
    public void action()
    {
        this.command.execute();
    }

}

  调用者就像受气包，不管什么命令，都要接收、执行。下面的代码时调用命令模式。

package CommandPattern;

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

3. 命令模式的应用

3.1 命令模式的优点：

•    类间解耦

    调用者角色与接受者角色之间没有任何依赖关系，调用者实现功能时只需要调用Command抽象类的execute方法就可以，不需要了解到底是哪个接收者执行的；

•    可扩展性

    Command的子类非常容易扩展，而调用者Invoker和高层次的模块Client不产生严重的代码耦合

•    命令模式结合其他模式会更优秀

    命令模式可以结合责任链模式，实现命令族解析任务；结合模板方法模式，则可以减少Command子类的膨胀问题。

3.2 命令模式的缺点

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

3.3 命令模式的使用场景

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

4. 命令模式的扩展

    反悔问题，有两种方法可以解决：一是结合备忘录模式还原最后状态，该方法适合接受者为状态的变更情况，而不适合事件处理；而是通过增加一个新的命令，实现事件的回滚。