在沒有setter的情況下使用依賴注入是不好還是很好的做法？

Question

如果我的課堂只有私人領域的容器注入會怎麼樣？這是好還是壞？在那種情況下，我必須在測試中使用DI框架（並且可能並不壞），但在另一方面，沒有設置者沒有不必要的代碼。不好還是不好？

Answer 1

strong text **首先，通過setter方法DI有哪些替代方案？ Martin Fowler區分three ways：**接口，二傳和構造函數注入。所以這些方法都不是好的或壞的定義，這是你如何使用它們以及最適合你的系統的方式。如果你希望你的字段在創建對象後不可改變，請使用帶有私有字段的構造函數注入。 儘管如此，Setter注入是DI最常用的方式，幾種框架依賴它。如果你不確定這樣去。你還會發現很多關於它的信息。

如果您的問題針對的使用制定者所有，問題是如果你的類是一種數據結構（見馬丁的Clean Code 6章詳細信息）。換句話說，如果您的班級沒有其他目的而不是持有一些數據，並且您可以公開您的字段（*）。如果它擁有業務邏輯，則使用私有字段和getter/setter。

（*）我個人不同意這一點，但那只是我。 :-)

Answer 2

Setter方法是實現抽象的方式，這是OOP最重要的原則之一。理想情況下，代碼不應該依賴容器。我認爲setter方法將提供使用DI的標準方式，並且具有良好的代碼可讀性。除非我的類實例化依賴於其他一些依賴項（我將使用基於構造函數的DI），否則我總是認爲setter DI是一種好的做法。

我認爲你不應該依賴容器來執行DI。

希望這會有所幫助。

Answer 3

必須使用DI框架進行測試非常沒有吸引力，測試將會涉及更多並且運行速度會變慢。這本身就夠糟糕，我不會主張這種方法。與構造函數注入和最終字段一起使用可以進行容器外測試，同時還可以完成確定字段內容的工作。