Tell的好例子，不要问

Question

说我有两个对象：

Map
Table

目前我有这样的事情：

Map.MapTable(Table tab); <- Static MapTable method.

检查表是否可映射，然后映射它，但也必须检查空表。

这样做更有意义：

Table tab = new Table();
Map mymap = tab.MapTable();

这样，表负责检查它自己的状态和任何检查，然后创建一个新的地图。

编辑：更多信息

我还有一个MapTables方法，它接受一组表，因为一个映射可以包含许多表，如：

Map.MapTables(ICollection<Table> tab)

这是否意味着我应该将map命令留在Map类型上。

您怎么看？

Answer 1

Table了解Map是否有意义，反之亦然？

• 如果Table知道Map s，那么Table.AsMap()或Table.ToMap()实例方法 - 您的告诉 - 请求解决方案 - 会有意义的。 （我想第一个是实时视图，第二个是静态副本。）

• 如果Map知道Table s，那么Map.FromTable(Table)静态方法 - 您的原始解决方案 - 是有道理的。

任何一种方式都可以工作，可能两种方式 - 取决于你的其余代码。依赖关系自然会走哪条路？

如果对于了解另一个没有意义，那么TDA解决方案可能有点微妙：创建一个实例方法Table.Populate(SomethingPopulatable)，并有一些TableMapper来调用它将SomethingPopulatable传递给名为Map.BuildFrom(SomethingPopulatable)的静态方法。

但是走这条道路的事情确实有点冒险Architecture Astronaut。

Answer 2

我认为他们中的任何一个都属于“告诉，不要问”的类别，因为在这两种情况下，你都要完全委派工作 ，而不是做一堆'如果表是这样做那种'逻辑。

在不了解问题领域的情况下，除此之外很难说。将一个数据结构转换为另一种类型的结构感觉就像自由函数可能实际上做的事情一样，并且它阻止了对Map类添加对Map的依赖，这是一件好事。

Answer 3

我投票支持保持表类中所有表格相关的逻辑（你提出的第二个解决方案）

甚至是这样的......

Table tab = new Table();
Map mymap = tab.CanMap ? new Map(tab) : null;

这样Table.CanMap属性包含确定映射是否可行的所有逻辑。

Answer 4

在您的环境中，将地图创建为表格可以做的事情是否自然？映射表是否涉及很多表的成员？是否有许多业务规则不是特定于创建地图所​​涉及的表？

答案取决于您的域名，这些是我在做出决定时会提出的一些问题。