2

假设我有两个对象：

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 类型上。

你怎么看？

4

4 回答 4

1

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

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

于 2009-08-08T08:47:35.687 回答
1

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

  • 如果Tables 知道Maps，那么一个Table.AsMap()或Table.ToMap()实例方法——你的告诉 - 不要问的解决方案 - 将是有意义的。（我想第一个是实时取景，第二个是静态副本。）

  • 如果Maps 知道Tables，那么Map.FromTable(Table)静态方法（您的原始解决方案）是有意义的。

无论哪种方式都可以工作，可能两者都可以 - 取决于您的其余代码。依赖项自然会朝哪个方向发展？

如果任何一方都无法了解另一方，那么 TDA 解决方案可能会更巧妙一些：创建一个实例方法Table.Populate(SomethingPopulatable)，并有一些TableMapper调用它并将 传递SomethingPopulatable给一个名为的静态方法，例如Map.BuildFrom(SomethingPopulatable)。

但是沿着这条路走下去，事情确实会冒着有点建筑宇航员的风险。

于 2009-08-06T13:50:21.737 回答
0

我投票赞成在表类中保留所有与表相关的逻辑（您提出的第二个解决方案）

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

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

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

于 2009-07-02T04:08:16.697 回答
0

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

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

于 2009-07-02T04:08:58.333 回答