正确的命令设计模式实现需要链接到接收器吗？

每个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); 
    } 
}

该命令指示机器人在建筑工地上移动块。注意命令的实例没有提及接收器（机器人）的实例;相反，命令依赖于Invoker（在我的情况下为RobotCommandCenter）来提供Robot的实例来执行该命令。

我深信，一个命令是一个命令，它应当仅封装的意图，应该不负责指定命令的目标。就我而言，作为一个用户，我并不在乎使用哪个机器人来执行作业。

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

来源

2012-03-12 THX-1138

首先，没有设计模式警察。它总是开放的解释和灰色的色调。

其次，维基百科是不是原始卷好，使这本书:)

GoF的列表中的Command模式为目的的投资：

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

如果你遇到这些意图中的任何一个，我会说你可以称之为命令的衍生物。

如果一个命令持有执行或调用所需效果的逻辑，则可以通用地告诉某个命令，从而释放命令引用的持有者处理这些细节。通常这样封装，你可以做一些很酷的事情，比如把它们放在一个列表中，并使用基本中定义的通用Execute方法来非常干净地执行Redo和Undo。

如果您的基类定义了Execute，并且您的调用代码将所有命令传递给机器人引用，那么您将拥有一个Command，但其中一个具有策略或轻量级方面，允许您更改命令的目标。我可以看到这方面的用途，尽管以undo/redo为代价。

来源

2012-03-12 21:02:01 tcarvin

我有书，无法链接，所以我指的是来源。没有“英国警察”这样的东西，并不意味着“我很好”是正确的。请注意，我问我的实现是否是“技术上”的命令设计模式。 – 2012-03-12 21:18:06

@ THX-1138这就是我的意思，但我不知道Command模式有一个“技术定义”。我想用我的“设计模式警察”的幽默声明来说，这是主观的。我的意见如我上面所述。 – tcarvin 2012-03-13 11:58:26

正确的命令设计模式实现需要链接到接收器吗？

回答

相关问题