命令模式返回状态

Question

有一次我讨论了与命令模式相关的设计。 我的同行指出，在调用 .execute() 方法后，命令对象不应返回状态（成功、不成功以及原因）。 原因是您不应该关心命令是否被执行，因为命令必须不包含任何状态。 但是，您必须在调用后检查该命令是否具有预期效果。 他争论的另一点是，在“四人帮”中，命令模式并没有呈现这种情况（返回状态）。

我主张相反的观点。 GoF 不提供这种情况，但可以根据您的需要对模式进行建模。 如果命令不成功，调用客户端必须收到状态证明，并最终部署适当的反应。 通过强制客户端检查操作是否成功，很容易出错并产生重复的代码。 此外，在某些情况下，命令会产生结果（例如，向绘图添加一条线的命令，将以某种方式将线 ID 返回给客户端），并且假装具有没有状态的命令意味着您必须从数据模型中“找出”新的对象标识符。

最后，我们达成了妥协，不返回状态，而是将新创建的对象的 id 保留在命令对象中，并且应用程序无论如何都运行得很好，但我现在也很想知道您的意见。

Answer 1

目前我面前还没有《设计模式：可重用面向对象软件的元素》，但我很确定作者甚至说他们提出的设计模式是一个可以修改以适应特定需求的模型。情况。

这个问题切入了设计模式的核心——模板。 这不是必须按书本执行的事情。 您确定了一种情况，对书中介绍的模式进行逻辑修改会对应用程序有所帮​​助，这完全没问题，尤其是在您权衡了收益和成本之后。

Answer 2

问题中有两个问题有多个答案:)
第一个问题是命令是否应该返回错误状态？

每个程序都没有明确的答案，每次应用该模式时，您都必须重新考虑。

您需要考虑的事情之一是：

• 我是否仅针对某些特定的错误情况向许多命令和客户端添加更多耦合？

在最坏的情况下，您有许多命令不关心错误，但一两个命令会执行一些对于客户端了解其是否有效很重要的操作。 现在，您将检查的异常添加到接口中，因此每个客户端和每个命令都必须执行错误处理并与异常耦合。 如果您的客户端仅处理不抛出异常的命令，那么您的代码会产生很大的开销。

这是你不想拥有的东西。 因此，您可以将需要错误处理的命令移出命令结构，因为它们似乎与其他命令不同，或者如果您的语言允许，您可以添加仅由关心并抛出的客户端处理的运行时异常需要抛出它们的命令。

另一个极端是每个命令都可能失败，并且客户端有一致的方式来处理错误，这意味着错误不依赖于特定的命令。 客户端不必知道哪种命令失败了，它可以以相同的方式处理每个错误。 现在您可以让命令的接口返回错误状态，并且客户端可以处理错误。 但处理错误不应取决于客户端命令的类型。

第二个问题是：命令应该有状态吗？

在某些体系结构中，命令需要状态，而在某些体系结构中，命令不需要状态。

决定这一点的一些可能性：

• 如果您想撤消命令，则命令需要有一个状态。

• 如果命令仅用于隐藏作用于一小组参数的函数的方式，并且结果仅取决于与状态模式相同的命令，则不需要状态，您可以使用同一个物体一遍又一遍。

• 如果您使用该命令在线程之间进行通信，并且希望将数据从一个线程传输到另一个线程，则该命令需要一个状态。

• ...如果您认为此列表中应该包含某些内容，请发表评论。

Answer 3

我将参考“Head First 设计模式”。 他们用于命令模式的示例是：

1. 就餐者场景（顾客创建订单，服务员通过向厨房工作人员喊叫来调用它，厨房工作人员接收订单）
2. 远程控制场景（人们单击按钮，远程控制 ）控制调用命令，设备接收它）

显然，在第一种情况下，接收者会产生某种状态：“这是幼虫”，或“我们没有黑麦面包了”。 在一家高档餐厅，您可以通过更高级别的异常处理来做到这一点（领班来到餐桌上道歉，提供替代品并为您准备甜点），而服务员除了正确调用命令之外什么都不用做。 但在餐馆里，也许厨师会继续用黑面包代替——服务员（和顾客）需要能够处理这个问题，而不必盯着柜台想知道“我的黑麦金枪鱼在哪里？” 这本书没有直接解决这个问题，但我认为这显然是一个有效的案例。

但在第二种情况下，调用者被故意弄得愚蠢。 如果出现问题，它不会向您显示错误，它只是根本没有任何效果。 所有的智能都在客户端中，以确定其命令是否及时成功（“糟糕，我忘了插入它”），或者在接收器中确定要做什么（“播放 CD：关闭 CD 托盘”）第一的”）。

我不是专家，但我想说，对于某些应用程序来说，将状态返回给调用者是完全可以的。

Answer 4

非常好的讨论。 我已经研究这个哲学问题几个小时了，我找到了一个满足我痴迷的解决方案。 （我喜欢这个东西的原因是它结合了具体和抽象的逻辑——布尔+设计。）

我简单地考虑过使用异常来返回结果。 我放弃了这个想法，因为在许多情况下，它会消除解耦，即模式本身的核心，正如你们中的一些人所指出的。 此外，结果通常不是异常，而是标准返回值。 我可能会得溃疡。

最终，我编写了一个客户端，它用自身实例化接收器，将接收器中的所有逻辑保留在其所属的位置。 客户端只需调用命令的execute() 并继续。 然后接收者可以调用客户端上的公共方法。 没有什么可以回报的。

这是一些示例代码。 我没有编写命令类，因为我想即使没有它你也会明白的。 它的execute()方法调用接收者的run()方法。

客户端：

Class ClientType{

    CommandType m_Command;
    ReceiverType m_Receiver;
    boolean m_bResult;

    ClientType(){

      m_Receiver = new ReceiverType(this);
      m_Command = new CommandType(m_Receiver);
    }

    public void run(){  
            ... 
      m_Command.execute();
    }


    /*  Decoupled from both the   
     *  command and the receiver. 
     *  It's just a public function that
     *  can be called from anywhere. /
    public setResult(boolean bResult){
      m_bResult = bResult;
    }
}

接收者：

Class ReceiverType{

    ClientType m_Client;
    boolean m_bResult;

    ReceiverType(ClientType client){
      m_Client = client;
    }

    public void run(){
            ...
      m_Client.setResult(m_bResult);    
    }
}

乍一看，我似乎违反了解耦要求。 但请考虑客户端对接收方的实现一无所知。 接收者知道调用客户端上的公共方法这一事实是标准费用。 接收者总是知道如何处理他们的参数对象。 没有依赖性。 接收者的构造函数采用 ClientType 参数这一事实是无关紧要的。 它也可以是任何物体。

我知道这是一个老话题，但希望你们中的一些人能再次参与进来。 如果您发现任何缺陷，请随时让我心碎。 这就是我们所做的。

Answer 5

这绝对是值得商榷的，但它清楚地表明了两种思维方式：

• 检查某事是否正常，然后进行相应
• 处理 无论如何都继续进行，如果发生不好的事情则处理它

我不认为一种方法比另一种更好。 例如，在 Java 中，通常最好不要滥用异常处理，并在简单地将双手（和异常）抛向空中之前解决任何可能的问题。 对于 Python，更好的做法是继续尝试执行任何操作，而不管状态代码如何，并让任何异常都得到相应的处理。

是否希望命令模式返回状态实际上取决于您。

Answer 6

这里的问题可能是该命令将由某个执行器类执行，而该执行器类不直接了解该命令的实际用途。

如果我们谈论向执行方法添加返回类型，则有可能向执行器公开实现特定的返回类型。 我的意思是，您正在为不同的命令可能具有不同的返回值集的情况打开一扇门。 如果执行器必须处理这些，那么它将与命令实现更加紧密地耦合。

但是，我经常给出命令状态 - 允许客户端在构造时为它们配置工作值，然后提供 getter 以允许客户端在完成时提取命令执行的结果。 在这种情况下，我可能没有严格遵循命令模式 - 但设计效果很好 - 除非有明确的代码味道 - 这真的是一个问题吗？

注意：也就是说，我很想听听关于为什么这可能是代码异味的想法。

Answer 7

正如你的问题中所说：

如果命令不成功，
调用 CLIENT 必须收到证明
状态，并最终部署
适当的反应。

在这种情况下，我会抛出运行时异常作为状态，其中包含有关它的必要信息。 你可以尝试一下。

问候，

Answer 8

另一个妥协是在可能失败的具体命令上公开属性“异常处理程序”。 这样，命令的创建者就可以处理异常，并且您不会向客户端添加代码开销。 当大多数命令不应失败时，这非常有用。

Answer 9

在我的 CAD/CAM 软件中，包含命令的程序集引用包含接口和对象层次结构的程序集，这些接口和对象层次结构保存了我的软件的各种 UI 元素。 它类似于 被动视图

命令可以通过视图界面操作 UI，自行报告任何错误。

基本上，

表单实现 IFormInterfaces 并在 EXE 中向 ScreenView 注册自己。

ScreenObject 实现 IScreenView 并向 ScreenView 程序集注册自己，并从命令程序集中获取

命令

。查看接口并保存应用程序实现。