建設者應該做多少工作

這是一個理論問題，我猜我正在使用它來爲此找到標準過程。建設者應該做多少工作

如果我有一個構造函數方法可以完成大量的數據收集等設置操作，我應該在構造函數中保留「所有東西構造」還是應該從構造函數中調用其他方法（代碼看起來基本上），還是我應該初始化我必須做的所有事情，並在以後處理其他事情，如果實際需要的話？

這裏是一個例子。

我正在創建一個基本上是一個集合管理器的對象。它需要從文件讀入數據並將其存儲在數組中。

我是否使用構造函數來創建一個具有基本屬性的對象，並在稍後讀取數據，或者我應該讀取所有信息並在構造函數中設置數組，以節省時間，但在這裏佔用額外的時間，或者我應該做的沿

public myConstructor(String filename) { 
data = readDataIn(filename); 
}

線的東西這不是實際的代碼，只是到「靚起來的代碼」，而不是一個超長的構造方法，我可以有發言權5外包給不同的方法的例子6個只能由構造函數訪問的簡短且好看的方法。

來源

2011-09-04 Andy

你是否期待構造函數如何「超長」？你有沒有考慮過你的班級嚴重違反SRP的可能性？ –

@karl，是的，我有。我主要問的只是「知道」，還因爲我有一種感覺，我違反了某件事情，因爲它沒有感覺到正確....：P – Andy

構造函數應該做足夠的工作來讓實例進入滿足其合約的狀態。然後，每種方法都應該做足夠的工作來完成方法的合同，並使實例處於滿足其合同的狀態。

構造函數調用很少引起副作用或修改其輸入。這些通常不需要滿足合同。例如，一個連接類不應該在構建時觸及網絡。由於它必須是可以關閉的，所以封閉狀態必須是它的合約的一部分，所以「恰到好處的工作」標準表明構造函數將它置於一個準備好但尚未開放的狀態。

您的特殊示例將您的課程連接到文件系統。您可能會使用Guava Files來進行閱讀，然後用內容替換字符串，從而獲得更可測試，更一般的類。通過編寫方便的static MyClass fromFile(String path)工廠函數，您可以獲得與文件系統耦合的構造函數的便利性，該工廠函數的作用是new MyClass。這會將您的代碼中與文件系統耦合的部分移動到與實例變量進行交互的部分之外，從而減少可能進行交互的測試數量。正如其他人所指出的，依賴注入是實現解耦的另一種好方法。

來源

2011-09-04 20:55:54

謝謝，這正好解釋了我正在尋找的東西。 – Andy

真的取決於你的API風格。請注意，您可能希望有多個構造函數，如：

public MyThing(String filename) { } 
public MyThing(FileInputStream filestream) {} 
public MyThing(File file) { } 
public MyThing(byte[] rawdata) { }

在該公司明智的鞏固文件加載操作到一個方法或兩個（文件打開和文件解析）

來源

2011-09-04 20:56:48

在這種情況下，我會使用依賴注入，以便您的構造函數需要已經計算好的數據，並將計算推遲到調用構造函數的地方。我可能會提供一個額外的靜態工廠函數來完成所有這些複雜的設置，以便於構造這個對象（例如在測試中），但是至少這個類的用戶能夠提出一個更聰明的（可能是並行的或者懶惰初始化的）創建這個類的方法。

來源

2011-09-04 21:01:49

建設者應該做多少工作

回答

相關問題