2010-10-28 105 views
3

這是一個關於依賴注入的問題。在構建服務對象時,我們在構建階段通過構造函數傳入協作者。服務對象將實現一個接口,並在運行階段調用該接口。通過構造函數傳遞什麼以及通過接口傳遞什麼?

有時候很難知道一個特定的對象應該通過構造函數傳遞還是成爲服務類實現的接口的一部分?

是否有關於選擇其他選項的規則?當你知道接口只會在你編碼的場景中被調用一次時,這個問題是非常困難的。

回答

5

我喜歡把它像這樣:

  • 構造函數參數的實施細則
    • 他們作用域所有操作
    • 他們沒有迴應更改爲任何操作(不變)
    • 無需他們即可理解界面
    • 它們是反映應用程序接縫的配置值
  • 方法參數是上下文
    • 它們限定一個單獨運轉
    • 它們反映運行時的值的應用程序的數據流

很多現有技術是在取景正確的問題。例如,我們可能會對自己說:「我需要在用戶表中創建一個新行。」從這個角度來看,無論是這些簽名似乎很動聽:

void Insert(User user); 

void Insert(User user, IDbConnection dbConnection); 

但是,我們可以打破我們的任務定義:

意圖:創建一個新用戶

實現細節:一用戶是表中的一行

讓我們改爲將任務設置爲「我需要創建用戶」。這給了我們一個方法來評估上述兩個簽名,這有利於我們的意圖相匹配的:一般給人實實在在的成效

操作的意圖
void Insert(User user); 

分析其數據的適用範圍。

2

經驗法則我經常使用的是類是否可以在沒有傳入值的情況下運行,與構造函數的複雜性保持平衡。如果這個類在沒有參數的情況下不能正常運行,通常把它放在構造函數中是很好的。另一方面,如果這個類被設計爲做一些需要額外工作的事情,比如通過套接字接受連接,那麼這種工作通常應該延遲到稍後的功能。

相關問題