歡迎使用Spring Dependency Injection –字段，設置器，構造函數注入教程。 了解場注入 ， 二傳手注入和構造函數注入之間的區別。 借助代碼示例，我們將看到使用每個示例的好處以及為什么選擇一個而不是另一個。

有關Spring依賴注入的更多信息：

• Spring Setter依賴注入示例
• Spring構造函數依賴注入示例
• Spring字段依賴注入示例
• Spring依賴注入和控制反轉

總覽

在Spring框架中，依賴注入分為三種類型。 它們是場注入 ， setter注入和構造器注入 。 您可以絕對使用它們中的任何一個，它們的結果完全相同。 但是，基于易用性，可讀性，編碼標準或更好的編碼實踐，幾乎沒有差異。 在我們Swift了解這些差異之前，我們將了解所有三種類型的依賴注入 。

基于字段的依賴注入

@Component public class MyClass { @Autowired private DogsController controller; @Autowired private DogsService service; @Autowired private DogsDao dao; @Autowired private ApplicationProperties properties; //... // Business methods // }

基于Setter的依賴注入

@Component public class MyClass { private DogsController controller; private DogsService service; private DogsDao dao; private ApplicationProperties properties; @Autowired public void setController(DogsController controller) { this .controller = controller; } @Autowired public void setService(DogsService service) { this .service = service; } @Autowired public void setDao(DogsDao dao) { this .dao = dao; } @Autowired public void setProperties(ApplicationProperties properties) { this .properties = properties; } //... // Business methods // }

基于構造函數的依賴注入

@Component public class MyClass { private DogsController controller; private DogsService service; private DogsDao dao; private ApplicationProperties properties; @Autowired public MyClass(DogsController controller, DogsService service, DogsDao dao, ApplicationProperties properties) { this .controller = controller; this .service = service; this .dao = dao; this .properties = properties; } //... // Business methods // }

我們具有所有三種類型的依賴項注入的代碼參考。 讓我們在面向對象設計原則的一些重要方面進行評估。

可讀性

可讀性是人類對一個軟件程序或一個軟件程序的理解程度的判斷。 開發人員花費30％的時間編寫軟件，并花費70％的時間維護軟件。 可讀性提高了軟件的可維護性。 當開發人員查看課程時，他/她應該能夠Swift專注于課程的重要部分，而不會被樣板代碼或其他框架組件所分散。

讓我們對所有三個應用可讀性度量

• 現場注入 ：最好的。 更少的樣板代碼。 重點是業務邏輯。
• 構造函數注入 ：更好。 構造函數在視覺上與方法分開。
• 二傳手注射：最糟糕。 添加了4個實例方法。 從業務方法中刪除焦點。

用軟件編程的術語來說，如果對象在創建后不能被修改，則稱其為不可變 。 不變性是良好的面向對象編程的重要原則。 不變性為類帶來了線程安全性，狀態安全性和可讀性。

如果我們從不變性的角度看上面的例子。

• 構造函數注入 ：支持不變性。
• Setter注入 ：無固定性。
• 場注入 ：無固定性。

國家安全

對象很可能由使用者或基礎框架實例化。 對象本身應為實例化器提供規則或指導，以便他們將以正確的狀態調用對象。 如果對象沒有規定這種狀態安全性，則有可能將對象實例化為不完整或不正確的狀態。

注意 ：以上所有示例都是狀態安全的，因為Spring正在解析它們的依賴項，并且Spring將正確初始化所有字段，這些字段是@Autowired一部分。 但是某些使用者可能會使用new關鍵字實例化您的對象。 我們應該研究Spring框架之外的狀態安全性。

讓我們將State Safety措施應用于我們看到的所有示例。

• 構造函數注入 ：狀態安全。 該對象被實例化為完整狀態或完全不被實例化。
• setter注入 ：消費者使用無參數構造函數。 而且可能會錯過調用設置器之一或兩次以不同的值調用相同的設置器（復制粘貼錯誤）
• 字段注入 ：使用者使用無參數構造函數。 沒有有效的方法來設置對象的狀態。 唯一的選擇是使用反射設置私有字段。

實例字段太多

讓我們考慮具有6、7或更多字段的對象的情況。 當您將上述示例用于大量字段時，會發生什么情況。

場注入 ：看起來仍然更好，而且可讀性強。 依賴項被隔離在一個地方。

@Component public class MyClass { @Autowired private Service1 service1; @Autowired private Service2 service2; @Autowired private Service3 service3; @Autowired private Service4 service4; @Autowired private Service5 service5; @Autowired private Service6 service6; @Autowired private Service7 service7; @Autowired private Service8 service7; ????//... // Business methods // }

構造函數注入 ：丑陋！ 構造函數注入確實看起來很丑。 對于消費者來說也不容易使用。

@Component public class MyClass { private Service1 service1; private Service2 service2; private Service3 service3; private Service4 service4; private Service5 service5; private Service6 service6; private Service7 service7; private Service8 service7; @Autowired public MyClass(Service1 service1, Service2 service2, Service3 service3, Service4 service4, Service5 service5, Service6 service6, Service7 service7, Service8 service71) { this .service1 = service1; this .service2 = service2; this .service3 = service3; this .service4 = service4; this .service5 = service5; this .service6 = service6; this .service7 = service7; this .service7 = service71; } //... // Business methods // }

二傳手注射 ：不好。 它添加了8個額外的實例方法，僅用于設置依賴項。

@Component public class MyClass { private Service1 service1; private Service2 service2; private Service3 service3; private Service4 service4; private Service5 service5; private Service6 service6; private Service7 service7; private Service8 service7; @Autowired public void setService1(Service1 service1) { this .service1 = service1; } @Autowired public void setService2(Service2 service2) { this .service2 = service2; } @Autowired public void setService3(Service3 service3) { this .service3 = service3; } @Autowired public void setService4(Service4 service4) { this .service4 = service4; } @Autowired public void setService5(Service5 service5) { this .service5 = service5; } @Autowired public void setService6(Service6 service6) { this .service6 = service6; } @Autowired public void setService7(Service7 service7) { this .service7 = service7; } @Autowired public void setService7(Service8 service7) { this .service7 = service7; } //... // Business methods // }

我們是否應該考慮“實例字段太多”？

通過檢查 “ 太多實例字段” ，我們發現“ 字段注入”是最好的。 真正的問題是，我們是否應該重視太多領域的問題？

答案是不。
我們所有人都喜歡并遵循單一責任原則 。 如果您的班級依賴太多東西，則說明設計不正確。 采用更好的設計，您將不會看到這些問題。 我們不應該支持不良的設計案例。 因此，我們將不重視“實例字段太多”的情況。

在特殊的情況下，不可避免的是有太多字段，而丑陋的構造函數是一個大問題，您應該致電并進行Field Injection 。

結論

根據上面的代碼示例和事實，很明顯， 基于構造的依賴注入在所有情況下始終表現得更好。 即使我們從Spring Dependency Injection的角度來看我們的課程，構造函數注入仍然是最佳選擇。

注意：所有設計原則或更好的編碼標準以及我們在此處討論的內容都只是準則，而不是規則。 您只是足夠聰明，可以接聽電話并證明您要走的路。

快樂編碼！

翻譯自: https://www.javacodegeeks.com/2019/02/field-setter-constructor-injection.html

總結

以上是生活随笔為你收集整理的Spring依赖注入–字段vs设置器vs构造函数注入的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。