Java设计模式之——命令模式

命令模式简单介绍

命令模式，是行为型设计模式之一。命令模式相对于其他的设计模式来说并没有那么多的条条框框，其实它不是一个很“规矩”的模式，不过，就是基于这一点，命令模式相对于其他的设计模式更为灵活多变。我们接触比较多的命令模式个例无非就是程序菜单命令，如在操作系统中，我们点击“关机”命令，系统就会执行一系列的操作，如先是暂停处理事件，保存系统的一些配置，然后结束程序进程，最后调用内核命令关闭计算机等，对于这一系列的命令，用户不用去管，用户只需要点击系统的关机按钮即可完成如上一系列的命令。而我们的命令模式其实也与之相同，将一系列的方法调用封装，用户只需要调用一个方法执行，那么所有的这些被封装的方法就会挨个执行调用。

命令模式的定义

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

命令模式的使用场景

• 需要抽象出待执行的动作，然后以参数的形式提供出来——类似于过程设计中的回调机制，而命令模式正是回调机制的一个面向对象的替代品
• 在不同的时刻指定、排列和执行请求。一个命令对象可以有与初始请求无关的生存期
• 需要支持取消操作。
• 支持修改日志功能，这样当系统崩溃时，这些修改可以被重做一遍。
• 需要支持事务操作。

命令模式的 UML 类图

角色介绍：

• Receiver：接收者角色

该类负责具体实施或执行一个请求，说的通俗点就是，执行具体逻辑的角色，以刚才的“关机”命令为例，其接收者角色就是真正执行各项关机逻辑的底层代码。任何一个类都可以称为一个接收者，而在接收者类中封装具体操作逻辑的方法我们则称为行动方法。

• Command：命令角色

定义所有具体命令类的抽象接口

• ConcreteCommand：具体命令角色

该类实现了 Command 接口，在 execute 方法中调用接收者角色的相关方法，在接收者和命令执行的具体行为之间加以弱耦合。而 execute 则通常称为执行方法，如刚才所说的“关机的”操作实现，具体可能还包含很多相关的操作，比如保存数据、关闭文件、结束进程等，如果将这一系列具体的逻辑处理看作接收者，那么调用这些具体逻辑的方法就可以看作是执行方法。

• Invoker：请求者角色

该类的职责就是调用命令对象执行具体的请求，相关的方法我们称为行动方法，还是用“关机”为例，“关机”这个菜单命令一般就对应一个关机方法，我们点击了“关机”命令后，由这个关机方法去调用具体的命令执行具体的逻辑，这里的“关机”对应的这个方法就可以看做是请求者。

• Client：客户端角色

根据类图可以得出如下一个命令模式的通用模式代码：

/** * 接收者类 */public class Receiver {    /**     * 真正执行具体命令的逻辑的方法     */    public void action() {        Log.d("Receiver", "执行具体的操作");    }}/** * 抽象命令接口 */public interface Command {    void execute();}/** * 具体命令类 */public class ConcreteCommand implements Command {    private Receiver receiver;    public ConcreteCommand(Receiver receiver) {        this.receiver = receiver;    }    @Override    public void execute() {        //调用接收者的相关方法来执行具体的逻辑        receiver.action();    }}/** * 请求者类 */public class Invoker {    private Command command;    //持有一个对相应命令对象的引用    public Invoker(Command command) {        this.command = command;    }    public void action(){        //调用具体命令对象的相关方法，执行具体命令        command.execute();    }}public class Client {    public static void main() {        //构造一个接收者对象        Receiver receiver = new Receiver();        //根据接收者对象构造一个命令对象        Command command = new ConcreteCommand(receiver);        //根据具体的对象构造请求者对象        Invoker invoker = new Invoker(command);        //执行请求方法        invoker.action();    }}

命令模式实战

命令模式总体来说并不难，只是相对比较繁琐，你想想一个简单的调用关系被解耦成多个部分，必定会增加类的复杂度，但是即使如此，命令模式的结构依然清晰。大家小时候应该都玩过俄罗斯方块游戏，这里以古老的俄罗斯方块游戏为例，看看我们在命令模式下是如何操控俄罗斯方块变换的。一般来说，俄罗斯方块游戏中都有 4 个按钮，两个左右移动的按钮，一个快速落下的按钮，还有一个变化方块形状的按钮，这是比较经典的游戏原型。一个玩游戏的人相当于我们的客户端，而游戏上的 4 个按钮就相当于请求者，或者也可以称为调用者，执行具体按钮命令的逻辑方法可以看作是命令角色，当然，游戏内部具体是怎么实现的我们不知道，也不在这里探讨，仅作例子分析，最后真正执行处理具体逻辑的则是游戏本身，你可以看做是各种机器码计算处理来执行的具体逻辑，这里我们将它看作是接收者角色。逻辑分析比较清楚了，我们来将其“翻译”成代码，首先是我们的接收者，这里以俄罗斯方块游戏本身作为接收者角色。

/** * 接收者角色，俄罗斯方块游戏 */public class TetrisMachineReceiver {    /**     * 真正处理“向左”操作的逻辑代码     */    public void toLeft() {        Log.d("TetrisMachine","向左");    }    /**     * 真正处理“向右”操作的逻辑代码     */    public void toRight(){        Log.d("TetrisMachine","向右");    }    /**     * 真正处理“快速落下”操作的逻辑代码     */    public void fastToButtom(){        Log.d("TetrisMachine","快速落下");    }    /**     * 真正处理“改变形状”操作的逻辑代码     */    public void transform(){        Log.d("TetrisMachine","改变形状");    }}

TetrisMachineReceiver 类是整个命令模式中唯一处理具体代码逻辑的地方，其他的类都是直接或间接地调用到该类的对方法，这就是接收者角色，处理具体的逻辑。如上文我们所说，接收者类只是一个普通的类，任何类都可以作为接收者。接下来我们定义一个接口作为命令角色的抽象。

/** * 命令者抽象，定义执行方法 */public interface Command {    void execute();}/** * 具体命令者，向左移的命令类 */public class LeftCommand implements Command {    //持有一个接收者俄罗斯方块游戏对象的引用    private TetrisMachineReceiver machine;    public LeftCommand(TetrisMachineReceiver machine) {        this.machine = machine;    }    @Override    public void execute() {        //调用游戏机里的具体方法执行操作        machine.toLeft();    }}/** * 具体命令者，向右移的命令类 */public class RightCommand implements Command {    //持有一个接收者俄罗斯方块游戏对象的引用    private TetrisMachineReceiver machine;    public RightCommand(TetrisMachineReceiver machine) {        this.machine = machine;    }    @Override    public void execute() {        //调用游戏机里的具体方法执行操作        machine.toRight();    }}/** * 具体命令者，快速落下的命令类 */public class FallCommand implements Command {    //持有一个接收者俄罗斯方块游戏对象的引用    private TetrisMachineReceiver machine;    public FallCommand(TetrisMachineReceiver machine) {        this.machine = machine;    }    @Override    public void execute() {        //调用游戏机里的具体方法执行操作        machine.fastToButtom();    }}/** * 具体命令者，改变形状的命令类 */public class TransformCommand implements Command {    //持有一个接收者俄罗斯方块游戏对象的引用    private TetrisMachineReceiver machine;    public TransformCommand(TetrisMachineReceiver machine) {        this.machine = machine;    }    @Override    public void execute() {        //调用游戏机里的具体方法执行操作        machine.transform();    }}

从程序中可以看到，命令者角色类中的方法名称与 TetrisMachineReceiver 接收者角色类中的方法名称可以不一样，两者之间仅是一种弱耦合。对于请求者，我们这里以一个 Buttons 类来表示，命令有按钮来执行。

/** * 请求者类，命令由按钮发起 */public class Buttons {    private Command leftCommand,    //向左移动的命令对象引用            rightCommand,        //向右移动的命令对象引用            fallCommand,         //快速落下的命令对象引用            transformCommand;    //改变形状的命令对象引用    /**     * 设置向左移动的命令对象     *     * @param leftCommand     */    public void setLeftCommand(Command leftCommand) {        leftCommand = leftCommand;    }    /**     * 设置向右的命令对象     *     * @param rightCommand     */    public void setRightCommand(Command rightCommand) {        this.rightCommand = rightCommand;    }    /**     * 设置快速落下移动的命令对象     *     * @param fallCommand     */    public void setFallCommand(Command fallCommand) {        this.fallCommand = fallCommand;    }    /**     * 设置改变形状的命令对象     *     * @param transformCommand     */    public void setTransformCommand(Command transformCommand) {        this.transformCommand = transformCommand;    }    /**     * 按下按钮向左移动     */    public void toLeft() {        leftCommand.execute();    }    /**     * 按下按钮向右移动     */    public void toRight() {        rightCommand.execute();    }    /**     * 按下按钮快速下落     */    public void fastToButtom() {        fallCommand.execute();    }    /**     * 按下按钮改变形状     */    public void transform() {        transformCommand.execute();    }}

最后，由客户端来决定如何调用。

public class Player {    public static void main() {        //首先要有俄罗斯方块游戏        TetrisMachineReceiver receiver = new TetrisMachineReceiver();        //根据游戏我们构造 4 种命令        Command leftCommand = new LeftCommand(receiver);        Command rightCommand = new RightCommand(receiver);        Command fallCommand = new FallCommand(receiver);        Command transformCommand = new TransformCommand(receiver);        //按钮可以执行不同的命令        Buttons buttons = new Buttons();        buttons.setLeftCommand(leftCommand);        buttons.setRightCommand(rightCommand);        buttons.setFallCommand(fallCommand);        buttons.setTransformCommand(transformCommand);        //具体按下哪个按钮玩家说了算        buttons.toRight();        buttons.toRight();        buttons.fastToButtom();        buttons.transform();    }}

或许大家在看了这么一长篇代码之后心里肯定是一万只草泥马奔腾而过，明明就是一个很简单的调用逻辑，为什么要做的如此复杂呢？对于大部分开发者来说更愿意介绍如下的代码：

public class Player {    public static void main() {        //首先要有俄罗斯方块游戏        TetrisMachineReceiver receiver = new TetrisMachineReceiver();        //要实现怎样的操作方式，我们直接调用相关的函数就行        receiver.toLeft();        receiver.toRight();        receiver.fastToButtom();        receiver.transform();        }}

调用逻辑做的如此复杂，这是因为开发起来方便，每次我们增加或修改游戏功能只需改 TetrisMachineReceiver 类就行了，然后对应地改一改 Player 类，一切都很方便。但是，对开发者自己来说是方便了，那么，如果有一天开发者不在负责这个项目了呢？这样的逻辑留给后来者，没人会觉得方便。设计模式有一条重要的原则：对修改关闭对扩展开放，大家细细体会。

除此之外，使用命令模式的另一个好处是可以实现命令记录的功能，如在上例中，我们可以在请求者 Buttons 里使用一个数据结构来存储执行过的命令对象，以此可以方便地知道刚刚执行过哪些命令动作，并可以在需要时恢复，具体代码大家可自行尝试，这里不再给出。

总结

在命令模式中其充分体现了几乎所有设计模式的通病，就是类的膨胀，大量衍生类的创建，这是一个不可避免的问题，但是，其给我们带来的好处也非常多，更弱的耦合性、更灵活的控制性以及更好的扩展性，不过，在实际开发过程中是不是需要采用命令模式还是需要斟酌。