告诉，不要问的好例子
假设我有两个对象：
Map
Table
目前我有这样的东西：
Map.MapTable(Table tab); <- Static MapTable method.
它检查表是否可映射，然后映射它，但还必须检查空表。
这样做是否更有意义：
Table tab = new Table();
Map mymap = tab.MapTable();
这样表负责检查它自己的状态和任何检查，然后创建一个新的映射。
编辑：更多信息
我还有一个 MapTables 方法，它接受一组表，因为一个地图可以包含许多表，例如：
Map.MapTables(ICollection<Table> tab)
这是否意味着我应该将地图命令留在地图上类型。
你怎么认为？
Say I have two objects:
Map
Table
At the moment I have something like this:
Map.MapTable(Table tab); <- Static MapTable method.
which checks if the table is mappable and then maps it but also has to check for null table.
Would it make more sense to do this:
Table tab = new Table();
Map mymap = tab.MapTable();
That way the table is responsible for checking it's own state and any checks, then creates a new map.
EDIT: A bit more info
I also have a MapTables method which takes a collection of tables, as one map can contain many tables, something like:
Map.MapTables(ICollection<Table> tab)
Would this mean that I should leave the map command on the Map type.
What do you think?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
Table了解Map是否有意义，反之亦然？如果
Table了解Map，那么Table.AsMap()或Table.ToMap() 实例方法——你的“告诉不要问”的解决方案——是有意义的。 （我想第一个是实时视图，第二个是静态副本。）如果
Map了解Table，那么就是Map。 FromTable(Table)静态方法 - 您最初的解决方案 - 是有道理的。无论哪种方式都可以工作，也可能两者都可以——取决于代码的其余部分。 依赖关系自然会走向哪个方向？
如果双方都没有必要了解对方，那么 TDA 解决方案可能会更微妙一些：创建一个实例方法
Table.Populate(SomethingPopulatable)，并拥有一些TableMapper调用它并将SomethingPopulatable传递给名为Map.BuildFrom(SomethingPopulatable)的静态方法。但沿着这条路走下去，确实会有一点建筑宇航员的风险。
Does it make sense for
Tableto know aboutMap, or vice versa?If
Tables know aboutMaps, then aTable.AsMap()orTable.ToMap()instance method -- your tell-don't-ask solution -- would make sense. (I imagine the first would be a live view and the second a static copy.)If
Maps know aboutTables, then aMap.FromTable(Table)static method -- your original solution -- makes sense.Either way could work, possibly both -- depends on the rest of your code. Which way do the dependencies naturally seem to go?
If it doesn't make sense for either to know about the other, then a TDA solution could be a little subtler: create an instance method
Table.Populate(SomethingPopulatable), and have someTableMapperthat calls it and passes theSomethingPopulatableto a static method called, say,Map.BuildFrom(SomethingPopulatable).But going down that road things do risk getting a bit Architecture Astronaut.
我认为它们中的任何一个都属于“告诉，不要问”的类别，因为在这两种情况下，您都完全委派工作，而不是做一堆“如果表格是这样的，那么做这种逻辑。
如果不了解问题领域，就很难说更多。 将一种数据结构转换为另一种类型的结构感觉就像自由函数实际上可以做的事情，并且它可以防止将 Map 依赖项添加到 Table 类，这是一件好事。
I think either of them fall under the category of "tell, don't ask," as in both cases you're delegating the work entirely, not doing a bunch of 'if the table is this then do this' kind of logic.
Without knowing about the problem domain, it's hard to say beyond that. Turning one data structure into another type of structure feels like the kind of thing that a free function might realistically do, and it prevents adding a dependency on Map to your Table class, which is a good thing.
我投票支持在表类中保留所有与表相关的逻辑（您提出的第二个解决方案），
或者甚至是这样的......
这样 Table.CanMap 属性包含确定映射是否可能的所有逻辑。
I vote for keeping the logic for everything Table related in the table class (the second solution you proposed)
Or even something like this ...
that way the Table.CanMap property contains all the logic to determine if the mapping is possible.
在您的环境中，是否很自然地将创建地图视为表格的功能？ 映射表是否涉及很多表成员？ 是否存在许多不特定于创建地图所涉及的表的业务规则？
答案取决于您的领域，这些是我在做出决定时会提出的一些问题。
In your environment, is it natural to think of creating a map as something that a table would do? Does mapping the table involve a lot of the table's members? Are there many business rules which are not specific to tables involved in creating the map?
The answer depends on your domain, and those are some of the questions I would ask in making the determination.