侃侃無極
2019-09-19 09:32:19
我正在重構一個類并為它添加一個新的依賴項。該類目前正在構造函數中使用其現有依賴項。因此,為了保持一致性,我將參數添加到構造函數中。當然,對于單元測試,有一些子類加上甚至更多,所以現在我正在玩改變所有構造函數的游戲來匹配,并且它需要很長時間。這讓我覺得使用帶有setter的屬性是獲得依賴關系的更好方法。我認為注入的依賴項不應該是構造類實例的接口的一部分。您添加了一個依賴項,現在所有用戶(子類和任何直接實例化您的用戶)突然知道它。這感覺就像打破了封裝。這似乎不是現有代碼的模式,所以我希望找出一般的共識是什么,構造函數與屬性的優缺點。使用屬性設置器更好嗎?
3 回答

翻過高山走不出你
TA貢獻1875條經驗 獲得超3個贊
這要看情況 :-)。
如果沒有依賴項,類無法完成其工作,則將其添加到構造函數中。該類需要新的依賴項,因此您希望您的更改能夠破壞事物。此外,創建一個未完全初始化的類(“兩步構造”)是反模式(IMHO)。
如果類可以在沒有依賴項的情況下工作,那么setter就可以了。

絕地無雙
TA貢獻1946條經驗 獲得超4個贊
一般優選的方法是盡可能多地使用構造器注入。
構造函數注入準確地說明了對象正常運行所需的依賴項 - 沒有什么比新建一個對象更令人討厭,并且在調用一個方法時因為沒有設置某個依賴項而使它崩潰。構造函數返回的對象應處于工作狀態。
嘗試只有一個構造函數,它保持設計簡單并避免歧義(如果不是人類,DI容器)。
當你在他的書“.NET中的依賴注入”中使用Mark Seemann所稱的本地默認值時,你可以使用屬性注入:依賴是可選的,因為你可以提供一個很好的工作實現但是想讓調用者指定一個不同的實現需要。
(以下的答案)
我認為如果注入是強制性的,構造函數注入會更好。如果這會添加太多構造函數,請考慮使用工廠而不是構造函數。
如果注射是可選的,或者如果你想在中途改變它,那么setter注射是很好的。我一般不喜歡制定者,但這是一個品味問題。
添加回答
舉報
0/150
提交
取消