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

本文关键字：命令 返回 类型 许不同 设计模式 | 更新日期: 2023-09-27 18:27:41

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

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

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

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

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

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

我的实际问题是：

  • 你能想出更好的解决方案吗
  • 选项1、2和3有什么优点或缺点，选项4有什么优点吗

谢谢！

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

我怀疑命令模式正在扩展到它真正打破这里的模式的地步。你链接的帖子中的一条评论说得很好："这种模式的初衷是有一些对象执行命令，但不知道它们实际做了什么。"如果一个命令族是访问数据，另一个是对数据进行变异，那么真的有一个通用用例需要将它们抽象为一个通用类型吗？对我来说，一个通用接口表示两个对象以相同的方式使用，但这里的情况并非如此。

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

如果MV*对你来说太多模式了，那么我认为4是你的答案，去掉通用接口就行了。您不一定要有两个接收器，因为您可以使接收器上的方法通用。然而，我认为您必须根据处理的是CommandDoUpdates还是CommandGetData来做一些不同的事情，因此方法的重载可能比检查"命令"的返回类型更清楚。我认为，在这种情况下，让接收者的签名表明它从两种不同类型的对象接收消息比说这些"命令"基本上是同一类型更清楚。

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

作为一种替代方案，您可以使Command必须返回一个结果：

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

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

相关文章：