为告诉，不要问

说好了的情况下，我有两个对象：为告诉，不要问

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命令。

您认为如何？

来源

2009-07-02 Nathan W

我投保持在表类相关的一切表的逻辑（你提出的第二个解决方案）

甚至这样的事情...

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

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

来源

2009-07-02 04:08:16 Nippysaurus

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

答案取决于你的域名，这些都是我在作出决定时要问的一些问题。

来源

2009-07-02 04:08:58 Robert

对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。

来源

2009-08-06 13:50:21

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

不知道问题领域，除此之外很难说。将一个数据结构转换为另一种类型的结构感觉就像自由函数可能实际做的那样，并且它可以防止在Map类中添加依赖关系，这是一件好事。

来源

2009-08-08 08:47:35 kyoryu

为告诉，不要问

回答

相关问题