对命令模式感到困惑
我目前正在学习软件设计课程。我自己从来都不擅长设计软件系统，所以我认为这是弥补我的弱点的明智之举；）
我试图理解命令模式是如何工作的。我查遍了所有例子，但我仍然感到困惑。模式中每个类的职责是什么？具体命令是否实际执行操作，或者它们是否携带必要的信息并将其发送到适当的目的地以实际执行？
I am currently taking a software design course. I myself have never been really good at designing software systems so I thought it was a smart move to patch up my weakness ;)
I am trying to understand how the command pattern works. I have looked all over for examples, but I am still puzzled. What are the responsibilities of each class in the pattern? Do ConcreteCommands actually perform the action or do they carry the information necessary and send it off to the appropriate destination to be actually executed?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我见过命令模式有两种不同的变体。
第一个是用于执行任务或命令的简单界面。 Runnable Java 接口就是这样的一个例子。实现有一个简单的方法，例如“doSomething()”，它允许系统中的另一个组件执行该任务或命令。
命令模式的教科书版本甚至描述了将使用命令具体实现的系统的其他组件。这就是调用者、接收者和客户端等其他术语的由来。有关详细信息，请参阅维基百科：http://en.wikipedia.org/wiki/Command_pattern
不要让这种设计模式让您感到困惑，它就像拥有一个带有“doSomething()”定义的接口一样简单。
There are two different variations on Command pattern that I have seen.
The first is a simple interface used to execute a task or command. The Runnable Java interface is one such example. Implementations have a simple method such as "doSomething()" that allows that task or command to be executed by another component in the system.
The textbook version of the Command pattern goes so far as to describe the other components of the system that will use the Command concrete implementation. This is where the other terms such as Invoker, Receiver and Client comes from. Refer to Wikipedia for more information on this: http://en.wikipedia.org/wiki/Command_pattern
Don't let this design pattern confuse you, its as simple as having an interface with a "doSomething()" definition.
从科学的角度来说，命令模式是来自函数式编程领域的闭包的面向对象实现，并且应该相应地使用。
假设您有按钮控件：按下按钮时，应该执行一些操作。这个动作是ConcreteCommand。它可以是普通的函数指针（在 C 或 C++ 中）。但是，如果它需要来自其他控件或用户输入的附加信息，则也应该在某个地方捕获它们。因此，拥有一个可以捕获这些附加信息的对象会很方便。
作为副作用，您可以将命令存储在某个容器中并延迟其执行，或者您可以跟踪执行了哪些命令，或者您可以稍后回滚它们，等等。
Speaking scientifically, the Command pattern is OO-implementation of closures from Functional Programming land, and should be used accordingly.
Suppose you have button control: when it pushed, some action should be performed. This action is ConcreteCommand. It could be plain pointer-to-function (in C or C++). But if it needs additional information from, for example, other controls or user input, they also should be captured somewhere. For this reason, it is convenient to have an object that would capture this additional information.
As a side effect, you can store Commands in some container and delay their execution, or you can track which Commands where executed, or you can rollback them later, etc.
据我了解，命令模式的本质是捕获要执行的操作的数据（以便可以在适当的时间执行，而不是立即执行）。现在谁执行该操作并不那么重要。它可能是单独的命令处理程序类，也可能是命令类本身。
As i understand it, the essence of Command pattern is to capture data for the action to be performed (so that it may be performed at the appropriate time, rather than immediately). Now who performs that action is not that important. It may be separate command handler class, or it may be the command class itself.
假设您有一张纸，上面有与某个对象相关的分步说明。您将这张纸放入信封并密封。然后，您将信封交给您的朋友，知道当某些事件发生时，他会打开信封并完全按照此处所写的操作。
在这种情况下，您是客户。该文件是一个ConcreteCommand。 Receiver 是您在论文中提到的对象。 祈求者是你的朋友。
您可以通过选择调用者来选择打开信封的条件。
Suppose you have a piece of paper with step-by-step instructions relative to some object. You put this paper into an envelope and seal it. Then you give the envelope to a friend of yours knowing that he will open it and do exactly what is written here when some event happen.
In this case you're a Client. The paper is a ConcreteCommand. Receiver is the object you mentioned in the paper. And Invoker is your friend.
You choose the conditions under which envelope will be opened by choosing the Invoker.