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

Question

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

我们有两种主要类型的命令，它们将实现我们的IOurCommand接口(其他命令将继承这些命令)。

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

我们正在考虑如何处理这种情况：

1. 返回一个类，该类将包含操作成功的指示(奖励)和一个对象列表，该列表将是所有CommandDoUpdates的空列表。
2. 保持List作为一个具体的命令-潜在解决方案的成员，但使我们的生活更困难的其他原因(浅拷贝Vs。深拷贝等等)。
3. 与#1相同，但是在函数中返回一个基类，每个调用calss都必须将结果向下转换为具体的类(下行转换不是一个好的实践，因为客户端需要知道实际返回值是什么)。
4. 将命令拼接到两个不同的层次结构(一个返回值，另一个不返回)，并使用两个不同的接收者--我真的不喜欢它，但这是一个选项。

This post很好地阅读了命令是否应该返回值/状态。这是相关的，因为在GoF书中，命令设计模式不返回值。

我的实际问题是：

• 你能想出更好的解决办法吗？
• 备选方案1、2和3有任何利弊，备选方案4有哪些利弊？

谢谢!

Answer 1

我怀疑命令模式正在扩展到它真的破坏了这里的模式。您所链接的帖子中的一条评论说得很好：“这种模式的初衷是有一些对象执行命令，但不知道它们实际做了什么。”如果一个命令家族要访问数据，而另一个命令家族要对其进行变异，那么是否真的有一个公共用例需要将它们抽象成公共类型呢？对我来说，一个通用的接口说两个对象的使用方式是相同的，但这里的情况并非如此。

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

如果MV*对您来说是太多的模式，那么我认为4是您的答案，只需去掉公共接口。您不一定需要有两个接收器，因为您可以使接收器上的方法成为通用的。但是，我认为根据处理CommandDoUpdates还是CommandGetData，您必须做一些不同的事情，所以方法的重载可能比检查“命令”的返回类型更清楚。我认为，在这种情况下，让接收者的签名说它从两种不同类型的对象获取消息比说这些“命令”基本上是相同的类型要清楚得多。

另外，也许CommandDoUpdates作为事务脚本更好，而您的CommandGetData作为存储库更好，这两个层次结构可以重命名吗？关于上下文中是什么引导您首先使用命令模式的信息不多，只知道是什么使它不是正确的选择，所以我可能会因为这个而完全失去理智。

Answer 2

作为另一种选择，您可以使必须返回结果的Command：

• 通知观察者，或
• 将结果保存在可以通过getter检索的成员中。

我想，当您创建特定的命令时，您知道它是这样的，所以您可以为它分配一个观察者，或者在命令完成后得到它的结果。