Question

每个GoF设计模式（wikipedia），ConcreteCommand实例应该（必须？）具有到Receiver实例的链接（引用）。我有以下命令的实现：

internal class PutBlockOntoBlockCommand : ICommand {
    private readonly int _srcTower;
    private readonly int _dstTower;

    public PutBlockOntoBlockCommand(int srcTower, int dstTower) {
        _srcTower = srcTower;
        _dstTower = dstTower;
    }

    public void Execute(Robot robot, Construction construction) {
        robot.MoveBlocks(_srcTower, _dstTower, construction);
    }
}

此命令指示机器人在施工现场移动块。请注意，该命令的 instance 没有引用接收器（Robot）的实例;相反，该命令依赖于Invoker（在我的情况下为RobotCommandCenter）来提供Robot的实例来执行命令。

我确信，对于命令作为命令，它应仅封装意图，并且不负责指定命令的目标。就我而言，作为一个用户，我不关心将使用哪个机器人来执行这项工作。

所以我的问题是：将所提出的实现称为“命令设计模式”在技术上是否有效？

Answer 1

首先，没有设计模式的警察。它总是可以解释，并以灰色阴影着色。

其次，维基百科不如原始卷，在书中投资：）

GoF将Command模式的意图列为：

将请求封装为对象，从而允许您进行参数化具有不同请求，队列或日志请求以及支持的客户端可撤销的操作。

如果你遇到其中一个意图，我会说你可以把它称为Command衍生物。

如果它具有实现或调用所需效果的逻辑，则可以通过一般性来判断某个命令，从而释放命令引用的持有者处理这些细节。通常这是封装的，你可以做很酷的事情，比如将它们放在一个列表中，并使用基础中定义的常见Execute方法来非常干净地执行重做和撤销。

如果您的基类定义了Execute并且您的调用代码传递了Robot引用的所有命令，那么您有一个Command，但是具有策略或flyweight方面的Command允许您更改命令的目标。我可以看到这方面的用途，但代价是撤消/重做。

是否需要链接到接收器才能实现正确的命令设计模式？

1 个答案: