爲告訴，不要問

說好了的情況下，我有兩個對象：爲告訴，不要問

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

爲告訴，不要問

回答

相關問題