设计模式——命令模式

在阎宏博士的《JAVA与模式》一书中开头是这样描述命令（Command）模式的：命令模式属于对象的行为模式。命令模式又称为行动(Action)模式或交易(Transaction)模式。命令模式把一个请求或者操作封装到一个对象中。命令模式允许系统使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。

命令模式通过将用户的请求以命令对象的形式进行分装，然后将命令发送给具体的调用处理者。命令模式把发出命令的责任和执行命令的责任分割开，委派给不同的对象，因而达到命令的发送者和命令执行者之间的解耦。

UML图

命令模式.png

命令模式涉及到的五个角色：

• 抽象命令角色（Command）：定义声明所有命令指令类的规范行为。
• 具体命令角色（ConcreteCommand）：定义一个具体的命令角色，一般包含一个命令接受者的引用，通过在execute方法中调用具体的执行者进行执行。
• 接受者角色（Receiver）：该类负责具体实施或执行一个请求，充当了具体逻辑处理角色。
• 请求者角色（Invoker）：该类负责调用命令对象执行具体请求，相关的方法叫行动方法。

UML图不是固定的，在实际使用的过程中可随机应变，比如可以直接把Receiver定义成一个通用化的接受者来处理多个命令，或者通过工厂方法模式结合来处理多个命令的情况。

案例演示

我们都知道在小游戏中都存在上、下、左、右的操作指令，所以这次我们就以这种场景来模拟。

创建抽象Command指令和具体的指令

abstract class Command {
    protected Receiver receiver;
    public abstract void execute();
    public void setReceiver(Receiver receiver) {
        this.receiver = receiver;
    }
}

class UpCommand extends Command{
    
    @Override
    public void execute() {
        System.out.println("指令：向上");
        receiver.doCommand();
    }
}

class DownCommand extends Command{
    @Override
    public void execute() {
        System.out.println("指令：向下");
        receiver.doCommand();
    }
}

定义接受者Receiver

abstract class Receiver {
    public abstract void doCommand();
}

class UpReceiver extends Receiver{

    @Override
    public void doCommand() {
        System.out.println("执行者：向上");
    }
}

class DownReceiver extends Receiver{

    @Override
    public void doCommand() {
        System.out.println("执行者：向下");
    }
}

定义请求者角色Invoker

public class Invoker {
    private Command command;
    
    
    public Invoker(Command command) {
        super();
        this.command = command;
    }

    public void doCommand(){
        command.execute();
    }
}

定义客户端

public class Client {

    /**
     * @param args
     */
    public static void main(String[] args) {
        Command commandUp = new UpCommand();
        commandUp.setReceiver(new UpReceiver());
        Invoker invoker = new Invoker(commandUp);
        invoker.doCommand();
    }
}

上面就是一个命令模式的演示，在上面的模式中，通过继承实现多个对应类型的接收者，这里同样可以在一个接收者中完成。

优缺点

优点

1. 类间解耦：调用者角色与接收者角色之间没有任何依赖关系，调用者实现功能时只需调用Command 抽象类的execute方法就可以，不需要了解到底是哪个接收者执行。在我的理解中，可以直接把Receiver在Command中指定好，而不一定要在客户端进行动态绑定。这样或许会省事一些，但是扩展性需要考虑。
2. 可扩展性：Command的子类可以非常容易地扩展，而调用者Invoker和高层次的模块Client不产生严 重的代码耦合。
3. 命令模式结合其他模式会更优秀：命令模式可以结合责任链模式，实现命令族解析任务；结合模板方法模式，则可以减少 Command子类的膨胀问题。

缺点
命令模式也是有缺点的，如果有N个命令，问题就出来 了，Command的子类就可不是几个，而是N个，这个类膨胀得非常大，这个就需要读者在项 目中慎重考虑使用。