2.1 命令模式

作者: 刑天的脑袋 | 来源:发表于2016-08-15 20:18 被阅读56次

2.1 命令模式
vi 显示行号
iOS设计模式七(享元,代理,备忘录)
Activity的启动模式
2018-09-11
VirtualBox中CentOS.7设置网络连接
Docker命令集锦-镜像操作命令
12.vim的使用技巧
cocoapods制作私有framework
Linux日期时间查看和设置相关命令

命令模式是我最喜欢的模式之一。大部分我写的大型程序，游戏或者其他的程序，最后都是在某些地方使用了命令模式。当我在正确的地方使用它时，它真的干净整洁地清理了一些粗糙的代码。对于这样一个极好的模式，“四人帮”有一个预见性的深奥的解释：

把一个请求封装成一个对象，从而可以令用户用不同的请求作为参数表示客户端，可以对请求排队、记录，还可以支持撤销操作。

我认为我们都同意这个句子太糟糕了。首先，他损坏了他建立的所有隐喻。在单词可以代表任何东西的奇怪的软件世界，一个“client”，代表一个人-跟你做生意的某个人。最后，我核查，一个人是不能被“参数化”的。

然后，剩余的句子只是一个你有可能会使用模式的情况的列表。说的并不明确，除非你碰巧使用模式的情况在这个列表中。我对命令模式的简练的宣传就是：

一个命令就是一个具体化的调用方法。

当然，“简练”经常意味着“费解的简洁”，所以这可能并不意味着有多少进步。让我来分析分析。“具体化”，防止你从没听过，我解释一下，就是“让东西变得真实”。另一个术语解释具体化，就是使东西变成“一级”的类型。

译者注：详细见知乎

类型：规定了变量可以取的值得范围，以及该类型的值可以进行的操作。根据类型的值的可赋值状况，可以把类型分为三类：

一级（First Class）。该类型的值可以作为函数的参数和返回值，也可以赋给变量。

二级（Second Class）。该类型的值可以作为函数的参数，但不能从函数返回，也不能赋给变量。

三级（Third Class）。该类型的值作为函数参数也不行

如果函数是一级的，那么就称为一级函数。

两种说法都是采取一些概念并且把它变成一块数据-一个对象-你可以将其赋值给一个变量，作为参数传入函数，等等。所以说命令模式是个“具体化的函数”，其实就是包裹在对象中的函数。

这听上去像是“回调函数”，“一级函数”，“函数指针”，“闭包”，“偏应用函数”依据你使用的语言，实际上他们大致相同。“四人帮”后面又说：

命令是对回调函数的面向对象的替换。

这个是一个更好的解释相比之前的那个。

但是所有这些都太抽象和模糊了。我喜欢以具体的东西开讲，但是我搞砸了。为了弥补，从这里开始全都是最适合使用命令模式的例子。

Configuring Input

每个游戏的某个地方都肯定有一段代码用来读取原始的用户输入-按钮按下，键盘事件，鼠标点击，等等。它接受一个输入，并且把它转化为一个游戏中有意义的动作：

下面是一个简单死板的实现：

void InputHandler::handleInput()
{
    if (isPressed(BUTTON_X))
        jump();
    else if (isPressed(BUTTON_Y))
        fireGun();
    else if (isPressed(BUTTON_A))
        swapWeapon();
    else if (isPressed(BUTTON_B))
        lurchIneffectively();
}

这个函数通常会每一帧游戏循环（Game Loop）都会被调用，而且我很确定你能知道他是干什么的。如果我们想把用户输入到动作的映射写死，那么他的确能工作，但是，许多游戏允许用户配置输入到动作的映射。

为了支持这点，我们需要把那些直接调用的函数jump()和fireGun()变成可以交换的。“交换”听上去像赋值一个变量，所以我们需要一个对象用来代表一个游戏动作。走入：命令模式。

我们定义一个基类代表可以触发的游戏命令：


class Command

{

public:

    virtual ~Command() {}

    virtual void execute() = 0;

};

然后，我们为每一个不同的动作创建子类：


class JumpCommand : public Command

{

public:

    virtual void execute() { jump(); }

};

class FireCommand : public Command

{

public:

    virtual void execute() { fireGun(); }

};

// You get the idea...

在我们的输入处理类中，我们对每一个按钮定义一个command指针：


class InputHandler

{

public:

    void handleInput();

    // Methods to bind commands... 

private:

    Command* buttonX_;

    Command* buttonY_;

    Command* buttonA_;

    Command* buttonB_;

};

现在输入处理就委托给这些command了：


void InputHandler::handleInput()

{

    if (isPressed(BUTTON_X))

        buttonX_->execute();

    else if (isPressed(BUTTON_Y))

        buttonY_->execute();

    else if (isPressed(BUTTON_A))

        buttonA_->execute();

    else if (isPressed(BUTTON_B))

        buttonB_->execute();

}

原来输入直接调用函数，现在中间有了一个间接层：

这就是在壳中的命令模式，如果你已经看到了其中的价值，那么把剩余的部分当做福利吧。

Directions For Actors

我们刚才定义的那些Command类是为了用在上面这个例子，这相当局限。问题是我们假设有Jump()，fireGun()，等全局函数，这些函数会暗中找到玩家控制的角色并且可以控制角色像木偶一样跳舞。

这个假设的耦合限制了那些命令的使用。JumpCommand可以控制的角色也只有玩家一个。让我们减少那个限制。

我们传给函数我们想要控制的角色，而不是让函数自己找角色：


class Command

{

public:

    virtual ~Command() {}

    virtual void execute(GameActor& actor) = 0;

};