有時，您可能會聽說通過getter方法完成的依賴項注入，該方法會覆蓋子類或偽造測試框架。 它允許類具有一組設置的依賴關系，該依賴關系實際上是經過硬編碼的，但是可以根據需要“注入”。

從現在開始， 我已經寫過關于所謂的“公司編碼”依賴項的想法 。 不過，我在那篇文章中沒有提到吸氣劑注入，因為當時我還不太了解，現在我認為這并不是一個好主意。 我對第一個想出這種回旋方式做DI的人表示敬意，但這并不意味著我喜歡它。 我已經做了一些練習來弄出round回的做事方式，但這并不意味著我沒有意識到這是一個壞主意。

我不能說我的觀點應該是關于吸氣劑注入是否不良以及永遠不應該被觸及的最終裁決。 我只想說說我對此有什么反對，并討論更好的選擇。

什么是吸氣劑注入？

吸氣劑注入是指您使用吸氣劑方法進行硬編碼的“依賴注入”。 我使用引號是因為，因為它是硬編碼的，所以它不是真正的依賴注入。 “注入”依賴項的方式是通過子類化和覆蓋getter方法或通過使用反射（通常是使用模擬庫）替換它來更改getter。 我將舉一個繼承的例子。

public class ClassUnderTest {public void saySomething(){System.out.println(getString());}protected String getString(){return "Hello World";} }public class GetFrench extends ClassUnderTest {@Override protected String getString(){return "Bonjour le monde";} }

為什么吸氣劑注射不好？

我有什么反對吸氣劑注入的方法？ 簡而言之，我不喜歡它的最大原因是因為您的操作方式。 必須對要測試的內容進行子類化或模擬并不是一個好主意，因為這樣做可以使您不再測試相同的類。 您正在測試其他內容。

我不喜歡的另一個原因是因為人們可能很難理解。 測試代碼必須易于讀取和編寫，并且使用getter注入會在測試代碼中造成混淆。

我該如何解決？

上面的鏈接文章對如何進行“公司編碼”依賴項進行了完整描述，但是我將在此處進行快速概述。

您需要做的第一件事是提供一種設置字段以保存依賴項的方法。 最好的方法是通過構造函數（如果您當前具有公共構造函數，則應使用程序包私有的構造函數重載），因為它有助于設計不可變的類。 第二種選擇是提供使用該依賴項的方法的程序包私有重載，其中重載具有一個附加參數來獲取依賴項。 這種技術也非常適合不可變的設計。 否則，您可以使用package-private字段或setter來設置依賴關系。

下一步是確定依賴項是普通對象還是工廠。 如果舊的getter每次都產生一個新對象， 并且需要 ，則該依賴關系應該是工廠。

如果您想要更深入的解釋， 請查看我的舊文章 。

什么時候這不是一個壞主意？

盡管我對吸氣劑注入不滿意，但我對類似的東西也很滿意：模板模式。 如果將getter抽象化，以便它的唯一實現是通過子類，則可以。

奧托羅

那是我對吸氣劑注入的看法。 您可以不同意。 就我個人而言，我只是覺得這是依賴注入的最糟糕的選擇（緊接著使用“自動裝配” DI框架）。

翻譯自: https://www.javacodegeeks.com/2015/06/is-getter-di-a-good-idea.html

總結

以上是生活随笔為你收集整理的Getter DI是个好主意吗？的全部內容，希望文章能夠幫你解決所遇到的問題。

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