終於有人把依賴注入講清楚了，網友：鵝廠大佬，果然不一樣

在嘗試運用 Scalable Frontend 1 —Architecture Fundamentals 裡面所說的 Dependency Injection（依賴注入）時，感覺有些不清不楚，找了些資料，才更明白了一些，在此翻譯記錄部分聚合。

OriginMy GitHub依賴注入是什麼

在軟體工程中，依賴注入是一種一個物件接收它所依賴的其它物件的技術。這些其它物件稱為依賴。在典型的「使用」關係中，接收物件稱為客戶端（client），傳遞的（即「注入的」）物件稱為服務（service）。將服務傳遞給客戶端的程式碼可以是多種類型的東西，稱為注入器。注入器告訴客戶端要使用什麼服務，而不是客戶端指定要使用哪個服務。「注入」是指將依賴項（服務）傳遞到將使用它的物件（客戶端）中。

服務是客戶端狀態的一部分。將服務傳遞給客戶端，而不是讓客戶端構建或查詢服務，是該模式的基本要求。

優勢

依賴注入允許客戶端靈活地進行配置。只有客戶端的行為是固定的。客戶端可以對任何支援客戶端期望的內在介面的東西進行操作。依賴注入可用於將系統的配置詳細資訊外部化到配置檔案中，從而允許在不重新編譯的情況下重新配置系統。可以針對元件需要不同實現的不同情況編寫單獨的配置。這包括但不限於測試。因為依賴注入不需要對程式碼行為進行任何更改，所以它可以應用於遺留程式碼的重構。結果就是客戶端更加獨立，並且更容易使用存根或模擬物件進行單元測試。這種易測試性通常是使用依賴注入時注意到的第一個好處。依賴注入允許客戶端移除具體實現所需要使用的的所有知識。這有助於將客戶端與設計更改和缺陷的影響隔離開來。它增強了可重用性、可測試性和可維護性。減少應用程式物件中的樣板程式碼，因為初始化或設定依賴項的所有工作都由提供程式元件處理。依賴注入允許並行或獨立開發。兩個開發人員可以獨立開發相互使用的類，而只需要知道類將通過什麼介面進行通訊。插件通常是由第三方商店開發的，他們甚至從不與開發使用插件的產品的開發人員交流。依賴項注入減少了類與其依賴項之間的耦合。劣勢

依賴注入創建的客戶端需要由構造程式碼提供配置細節。當明顯的預設值可用時，這可能會繁重。依賴注入會使程式碼難以跟蹤（讀取），因為它將行為與構造分離開來。這意味著開發人員必須引用更多的檔案來跟蹤系統的執行情況。依賴注入框架是通過反射或動態程式設計實現的。這會妨礙 IDE 自動化的使用，例如「查詢引用」、「顯示呼叫層級」和安全重構。依賴注入通常需要更多的前期開發工作，因為不能在需要的時間和地點召集某樣東西成為正確的東西，但必須要求被注入，並且確保它已被注入。依賴注入迫使複雜性從類轉移到類之間的聯絡中，可能並不總是理想的或容易管理的。依賴注入可能助長基於依賴注入框架的依賴。依賴注入的幾種形式

客戶端物件至少有三種方式可以接收對外部模組的引用：構造器注入、設定器注入、介面注入。

構造器注入

依賴項是通過客戶端的類構器提供的參數傳入。

當可以首先構造所有依賴項時，最好使用它，因為它可以用來確保客戶端物件始終處於有效狀態，而不是使其某些依賴項引用為 null（不設定）。但就其本身而言，它缺乏在以後更改其依賴項的靈活性。這可能是使客戶端不可變從而實現執行緒安全的第一步。

設定器注入

這種方式需要客戶端提供一個設定器給依賴性。

要求客戶端為每個依賴項提供設定器。這樣就可以隨時自由地操作依賴項引用的狀態。這提供了靈活性，但是如果要注入多個依賴項，那麼客戶端很難確保在能夠使用之前已注入所有依賴項。

因為這些注入是獨立發生的，所以無法判斷注入器何時完成了與客戶機的連線。依賴項可能僅僅因為呼叫其設定器失敗而保留為 null 。這將強制檢查從客戶端組裝時到使用時的注入是否已完成。

介面注入

這只是客戶端將角色介面釋出到客戶端依賴項的設定方法。它可以用來確定在注入依賴項時注入器應該如何與客戶端對話。

介面注入的優點是依賴項可以完全忽略它們的客戶端，但是仍然可以接收對新客戶端的引用，並使用它，將自身的引用傳送回客戶端。這樣，依賴項就變成了注入器。關鍵是注入方法（可能只是一個經典的設定器方法）是通過一個介面提供的。