对命令模式感到困惑

Question

我目前正在参加软件设计课程。我自己从未真正擅长设计软件系统，因此我认为修补我的弱点是明智之举;）

我试图了解命令模式的工作原理。我看了很多例子，但我仍然感到困惑。模式中每个班级的责任是什么？ ConcreteCommands是否实际执行了操作，或者它们是否携带必要的信息并将其发送到适当的目的地以实际执行？

Answer 1

假设您有一张纸，其中包含有关某个对象的分步说明。你将这张纸放入信封并密封。然后你把信封交给你的一个朋友，知道他会打开它，并做一些事件发生时所写的内容。

在这种情况下，您是客户端。该论文是 ConcreteCommand 。 接收器是您在论文中提到的对象。 祈求者是你的朋友。

您可以通过选择 Invoker 来选择打开信封的条件。

Answer 2

我见过的Command模式有两种不同的变体。

第一个是用于执行任务或命令的简单界面。 Runnable Java接口就是这样一个例子。实现有一个简单的方法，例如“doSomething（）”，允许该任务或命令由系统中的另一个组件执行。

Command模式的教科书版本甚至描述了将使用Command具体实现的系统的其他组件。这就是Invoker，Receiver和Client等其他术语的来源。有关详细信息，请参阅维基百科：http://en.wikipedia.org/wiki/Command_pattern

不要让这种设计模式让你感到困惑，就像拥有一个带有“doSomething（）”定义的界面一样简单。

Answer 3

据我了解，Command模式的本质是捕获要执行的操作的数据（以便可以在适当的时间执行，而不是立即执行）。现在谁执行该行动并不重要。它可以是单独的命令处理程序类，也可以是命令类本身。

Answer 4

科学地说，Command模式是功能编程领域的OO实现闭包，应该相应地使用。

假设你有按钮控制：当它按下时，应该执行一些动作。此操作是ConcreteCommand。它可以是普通的指针到函数（在C或C ++中）。但是，如果它需要来自其他控件或用户输入的其他信息，那么它们也应该被捕获到某个地方。出于这个原因，有一个对象可以捕获这些附加信息。

作为副作用，您可以将命令存储在某个容器中并延迟执行，或者您可以跟踪执行的命令，或者以后可以回滚它们等等。