设计模式——命令模式

在阎宏博士的《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个,这个类膨胀得非常大,这个就需要读者在项 目中慎重考虑使用。

你可能感兴趣的:(设计模式——命令模式)