Invoker 类在命令设计模式中是可选的吗？客户端需要为命令实例化具体命令和接收器。客户端是否总是需要实例化 Invoker 并将命令对象传递给 Invoker 对象。稍后，每当客户端需要执行命令时，客户端只需询问 Invoker 对象，Invoker 就会执行命令（可能立即执行，也可能将命令排队等待稍后执行）。
或者这是相反的方式？如果客户端需要同步执行命令，客户端将使用基类接口引用命令，但会实例化具体的命令和接收器。每当客户端需要执行命令时，客户端只会调用基类命令变量的执行方法？当需要一些额外的逻辑来执行命令时，Invoker 类将用于保留该额外的逻辑，客户端将与 Invoker 对象交互以执行命令？
【问题讨论】：
标签： design-patterns command-pattern
命令模式的目的通常是 1) 使一组不同的操作共享相同的类型，以便它们可以由相同的代码处理 2) 将操作编组/创建与操作调用分开。目的 2 明确需要接收者。
如果您在创建后立即调用，或者如果 Reciever 扮演调用者的角色，则不存在单一用途、独立的调用者。这是否意味着没有调用者真的是一个哲学问题:)
这样看：你/可以/分开创建、调度和调用。这并不意味着您必须将它们实现为三个独立的类。这只是命令模式生命周期中涉及的逻辑角色。
编辑：我想单一责任原则认为你应该将它们分开，但是有常识这样的东西:)可以而且应该遵守当地条件。
【讨论】：
众所周知，java.lang.Runnable 是 Thread 类作为调用者工作的命令模式示例之一。我们将 Runnable 类的对象传递给 Thread 类并说 start/run。
但我们从不创建可以调用主线程的客户端类。
所以调用者不是可选的，但它不是与客户端紧密耦合的。所以命令模式的 UML 永远不会显示客户端类和调用者类之间的任何关系。
另一个answer与此问题相关。
【讨论】：