嗨，今天，我想簡單地討論將依賴項注入您的類的不同方式。

通常，您有以下三種注射方法

• 直接進入字段/屬性
• 通過顯式的setter方法
• 通過顯式的構造函數(shù)參數(shù)

現(xiàn)場注入

這種類型的注入為將所需的依賴項注入到類中提供了某種反射機制。

盡管這種注入類型的好處是，它消除了諸如setter方法或構造函數(shù)參數(shù)之類的混亂代碼，但其缺點是這些依賴性是不可見的。 如果從外部查看類，則只會看到公共方法，并且可能是構造函數(shù)。

即使這使您非常清楚地了解了類提供的服務，但在我看來，它仍然具有以下主要缺點：

在為此特定類編寫測試時，您必須檢查該類以查看所需的依賴項，并且必須使用DI框架（即使是簡單的測試），也必須使用一種反射機制來注入依賴項（模擬/存根/真實）。

更糟糕的是，傳入依賴項的數(shù)量隱藏在該類中。 當然，您可以使用工具（JDepend等，pp。）告訴您依賴性的數(shù)量和方向，或者使用一個文件來指定注入，但是您必須依靠這種工具或檢查類。

我觀察到的另一個缺點是，與使用Setter或Constructor Injection的情況相比，創(chuàng)建具有多個職責的類的機會更高。
就像是：

哦，讓我們使用這個精美的注解在這里注入我們需要的服務...幾天/幾小時后：測試這種野獸是如此的困難

二傳手注射

注入器注入工具注入器方法，每個依賴項一個，DI框架用于注入依賴項。

這是一個變體，它使依賴項顯式顯示，并且使您可以清楚地了解特定類的依賴項。

在測試過程中，它的好處是您不必使用DI框架或反射機制，而可以直接設置依賴項。

這種方法的缺點是：您可以構造處于無法使用狀態(tài)的類。 這是因為如果需要或可選依賴項，則無法與外部區(qū)分開。

構造函數(shù)注入

構造函數(shù)注入對類的構造函數(shù)進行檢測，DI框架使用該類來注入依賴項。 這是使依賴關系明確的另一個變體。

與Setter注入相反，它可以防止您在不規(guī)則狀態(tài)下創(chuàng)建類。 （當然，您可以傳遞null，但這不僅僅是一種作弊，對嗎？）所以我要說，這是最嚴格的變體：

每個依賴項都是強制性的

這種注射類型的好處是

您必須只閱讀一種方法，即構造函數(shù)，才能弄清楚此類的依賴關系。

您創(chuàng)建了一個不可變的類，它使緩存變得如此簡單

同樣，這里的缺點是您無法區(qū)分可選依賴項和必需依賴項。 構造函數(shù)強制設置所有字段。

我要討論的最后一個變體是：

混合二傳手和構造劑注射

我個人更喜歡此變體，混合了Setter和Constructor注入。

這給您：

• 在合同級別上區(qū)分強制性依賴項和可選性的能力
• 清楚說明特定類的依賴項是什么
• 使您可以輕松地檢查班級是否負有重大責任
• 構建后正確配置的類

與純方法類似，使用這種注入進行測試非常簡單。 您不需要DI框架，并且可以輕松地將模擬的/存根的/真實的實現(xiàn)傳遞到要測試的類中。

使用/喜歡什么？

這個答案在很大程度上取決于您的框架/團隊規(guī)則/語言。

但是我強烈建議您使用顯式注入變量之一，因為它們使您無需使用依賴注入框架即可編寫純單元測試。

翻譯自: https://www.javacodegeeks.com/2015/01/dependency-injection-field-vs-constructor-vs-method.html

總結

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。