Invoker 类在命令模式中的作用

Question

让我们假设我们以这种方式实现了命令模式

我对 Invoker 在这里的作用有点困惑。从我的角度来看：

1. 如果我们确实需要历史记录（或命令执行之前的任何类型的操作），那么创建这个类是有意义的。但是它打破了单一职责原则，是吗？现在它不仅是一个委托，它还在那里存储历史。
2. 如果我们不需要历史，我看不到创建这个调用程序的目标，它只是执行委托。唯一的原因是否只是一个假设，即我们将来在命令执行之前/之后需要某种逻辑？

或者我错过了什么？

Answer 1

如果我们确实需要历史记录（或命令执行之前的任何类型的操作），那么创建此类是有意义的。但它打破了单一责任原则，是吗？现在它不仅是一个代表，还在那里存储历史。

我完全同意安德烈亚斯的回答。如果您认为自己正在履行多项职责，请将其分解为不同的方法。

单一职责原则听起来不错，但我们不应该过多关注该原则。如果您严格遵循该原则，我确信代码库中充满了太多的小类。我认为软件行业中没有任何大型项目使用这个原则。我们能做的最好的事情是在同一类中针对不同的操作使用不同的方法。

如果我们不需要历史记录，我看不到创建此调用程序的目标，它只是执行委托。唯一的原因是否只是一个假设，即我们将来在命令执行之前/之后需要某种逻辑？

命令模式的核心 USP是Invoker。它将客户端（发送者）和接收者解耦。

来自oodesign文章：

客户端请求执行命令。Invoker 接受命令，将其封装并将其放入队列中，以防万一还有其他事情要做，而 ConcreteCommand 负责请求的命令，将其结果发送到 Receiver。

我已经在下面的 SE 问题中解释了Invoker的作用：

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