命令模式似乎不必要复杂(我不明白的是什么？)

Question

我已经阅读了命令模式,我想我错过了一些东西.Command对象的存在是为了抽象出Receiver对象的细节.在我看来,我们可以简单地停在这里,并保持对Command对象的引用,以在适当的时间执行适当的方法.

那么,为什么需要Invoker呢？这种额外的间接提供了什么优势？我们已经隐藏了命令后面的接收器的细节,那么命令随后被客户端隐藏的动机是什么？

Answer 1

如果您正在传递不同类型的命令，Invoker则很有用。您可以使用相同的 Invoker 来执行不同的具体命令。在不同的节点上，标记ReceiverwithConcreteCommand而不是Invoker允许松散耦合。所述Receiver可改变的方法的名称（例如合闸合闸到swithcOnTV）如在这个例子中：

相关文章：使用命令设计模式

要了解 的目的Invoker，我希望您参考这篇关于餐厅和汽车服务中心用例的文章。

服务员 ( Invoker) 从Customer他的垫子上接受订单。所述Order然后排队等待的顺序厨师和获取到厨师（Receiver），在其中被处理。

客户是Customer. 他Receiver通过服务员将他的请求发送给Invoker。服务员通过将命令写在支票上然后放置它来封装命令（在这种情况下是订单），从而创建ConcreteCommand作为命令本身的对象。

该Receiver会是做饭的是，在所有正在讨论的命令之前发送给他的命令完成工作以后，开始它的工作。

该示例的另一个值得注意的方面是订单垫不仅支持菜单中的订单，因此它可以支持烹饪许多不同项目的命令。

Answer 2

好吧，如果你这么说，它看起来相当复杂，但通常 Receiver 根本不需要是一个对象。它只不过是一个被执行的函数（作为一个事件）。此外，调用者不需要是一个类。它只是触发命令的东西。这也可以是按钮中的事件处理程序。

甚至维基百科也总结了几个使用此模式的示例，而实际上不必为调用者和接收者实现完整的单独的类。一个示例是向导对话框，其中 GUI 填充命令对象，并且“完成”按钮触发它。因此 GUI 类（无论如何你都有）既是客户端又是调用者。