5

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

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

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

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

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

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

我的实际问题是：

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

谢谢！

4

2 回答 2

1

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

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

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

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

于 2013-08-20T15:11:03.450 回答
0

作为替代方案，您可以使Commandthat 必须返回结果：

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

我想当您创建该特定命令时，您知道它属于那种类型，因此您可以为它分配一个观察者或在命令完成后获取它的结果。

于 2013-08-21T11:19:49.690 回答