命令设计模式——允许不同的具体命令返回不同的类型

Question

我们正在设计一个新组件并考虑使用命令设计模式。

我们有两种主要类型的命令来实现我们的IOurCommand接口（其他命令将从中继承）。

问题是第一个命令CommandDoUpdates不需要返回任何值，而第二个命令CommandGetData是获取数据，所以它需要返回List一些对象（List<DataRow>）

我们正在考虑处理这种情况的事情：

1. 返回一个 Class ，其中将包含有关操作成功的指示（奖励）和一个对象列表，该对象列表将是所有CommandDoUpdates.
2. 保持List作为具体命令的成员 - 潜在的解决方案，但由于其他原因（浅拷贝与深拷贝等）使我们的生活变得更加艰难。
3. 与 #1 相同，但在函数中返回一个基类，并且每个调用 calss 都必须将结果向下转换为具体类（向下转换不是一个好做法，因为客户端需要知道实际返回值是什么）。
4. 将命令分成两个不同的层次结构（一个返回值，一个不返回值），并使用两个不同的接收器 - 我真的不喜欢它，但这是一种选择。

这篇文章是关于命令是否应该返回值/状态的好读物。这是相关的，因为在 GoF 书中，命令设计模式不返回值。

我的实际问题是：

• 你能想到更好的解决方案吗？
• 选项 1,2 和 3 的任何优点或缺点，选项 4 的任何优点？

谢谢！

Answer 1

我怀疑命令模式正在扩展，以至于它真的打破了这里的模式。您链接的帖子中的评论之一说得很好：“这种模式的初衷是有一些对象执行命令，但不知道它们实际做了什么。” 如果一个命令系列是访问数据，另一个命令系列是改变数据，那么是否真的存在需要将它们抽象为通用类型的常见用例？对我来说，通用接口表示两个对象以相同的方式使用，但这里的情况并非如此。

就更好的解决方案而言，一种常见的解决方案是使用 MV*（MVC、MVP、MVVM）模式并让命令更新模型并在更新发生后通知观察者。

如果 MV* 对您来说模式太多，那么我认为 4 就是您的答案，只需摆脱通用接口即可。您不一定必须有两个接收器，因为您可以使接收器上的方法变得通用。但是，我认为您必须根据是否处理 CommandDoUpdates 还是 CommandGetData 执行不同的操作，因此方法的重载可能比检查“命令”的返回类型更清晰。我认为在这种情况下，让接收者的签名表明它从两种不同类型的对象获取消息比说这些“命令”基本上是同一类型更清楚。

另外，也许 CommandDoUpdates 作为事务脚本更好，而 CommandGetData 作为存储库更好，并且这两个层次结构可以重命名？没有太多关于上下文中是什么导致您首先使用命令模式的信息，只有什么使它不是正确的选择，所以也许我因此而完全离开。