這是一個關於依賴注入的問題。在構建服務對象時,我們在構建階段通過構造函數傳入協作者。服務對象將實現一個接口,並在運行階段調用該接口。通過構造函數傳遞什麼以及通過接口傳遞什麼?
有時候很難知道一個特定的對象應該通過構造函數傳遞還是成爲服務類實現的接口的一部分?
是否有關於選擇其他選項的規則?當你知道接口只會在你編碼的場景中被調用一次時,這個問題是非常困難的。
這是一個關於依賴注入的問題。在構建服務對象時,我們在構建階段通過構造函數傳入協作者。服務對象將實現一個接口,並在運行階段調用該接口。通過構造函數傳遞什麼以及通過接口傳遞什麼?
有時候很難知道一個特定的對象應該通過構造函數傳遞還是成爲服務類實現的接口的一部分?
是否有關於選擇其他選項的規則?當你知道接口只會在你編碼的場景中被調用一次時,這個問題是非常困難的。
我喜歡把它像這樣:
很多現有技術是在取景正確的問題。例如,我們可能會對自己說:「我需要在用戶表中創建一個新行。」從這個角度來看,無論是這些簽名似乎很動聽:
void Insert(User user);
void Insert(User user, IDbConnection dbConnection);
但是,我們可以打破我們的任務定義:
意圖:創建一個新用戶
實現細節:一用戶是表中的一行
讓我們改爲將任務設置爲「我需要創建用戶」。這給了我們一個方法來評估上述兩個簽名,這有利於我們的意圖相匹配的:一般給人實實在在的成效
操作的意圖void Insert(User user);
分析其數據的適用範圍。
經驗法則我經常使用的是類是否可以在沒有傳入值的情況下運行,與構造函數的複雜性保持平衡。如果這個類在沒有參數的情況下不能正常運行,通常把它放在構造函數中是很好的。另一方面,如果這個類被設計爲做一些需要額外工作的事情,比如通過套接字接受連接,那麼這種工作通常應該延遲到稍後的功能。