命令模式似乎不必要的复杂（我不明白什么？）

Question

我已经阅读了命令模式，我想我错过了一些东西。 Command对象用于抽象出Receiver对象的详细信息。在我看来，我们可以简单地在这里停下来，并持有对Command对象的引用以在适当的时候执行适当的方法。

那么为什么需要调用者？这种额外的间接提供了什么好处？我们已经隐藏了接收者在命令后面的细节，那么命令对客户隐藏的动机是什么？

Answer 1

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

即使Wikipedia总结了几个例子，其中使用这种模式，而实际上并不需要为调用者和接收者实现完整的单独的类。一个例子是向导对话框，其中GUI填充命令对象，并且完成按钮触发它。所以GUI类（无论如何）都是客户端和调用者。

Answer 2

从我所知道的情况来看，模式的要点是有某种命令生产者和某种命令使用者，但允许生产者创建或修改命令而不需要消费者改变。

该模式调用生产者“客户”和消费者“调用者”。

这是一个OO回调。

那么，为什么是祈求需要

至于我可以告诉all the examples on Wikipedia，调用者并没有一个明确的形式。它只是一些接受抽象命令的代码。

在我看来，我们可以简单地停在这里，并保持引用Command对象

如果它在你的调用命令，接受或容纳抽象指令引用的东西代码有道理，那么你已经实现了调用者。

如果一位代码既是生产者又是消费者，命令模式是毫无价值的。当你将抽象命令传递给某些想要调用它们的东西时，这才是值得的。

Answer 3

如果您通过不同类型的命令，Invoker是有用的。你可以使用相同的Invoker来执行不同的具体命令。在不同的节点上，标记Receiver与ConcreteCommand而不是Invoker允许松耦合。该Receiver可以改变方法（如合闸合闸到swithcOnTV）的名称，如本例：

相关岗位：Using Command Design pattern

要了解的Invoker的目的，我想你在餐厅&请参阅本article汽车服务中心使用案例。

服务员（Invoker）从他的垫上从Customer采取订单。然后将Order排队等待的顺序厨师，并得到在那里处理的厨师（Receiver）。

客户是Customer。他通过服务员，谁是Invoker送他的请求Receiver。服务员封装通过写它的检查命令（在这种情况下，指令），然后放置它，创造ConcreteCommand对象，它是命令本身。

的Receiver将是，对所有正在讨论的命令之前发送给他的命令完成下班后，就可以开始工作的厨师。

的例子中另一个值得注意的方面是，对于订单的垫不会从菜单中只支持订单，因此它可以支持的命令做饭许多不同的项目的事实。