依賴注入(DI)是控制反轉(IoC)的一種方式。
那麼在IoC模式中，被注入對象又是通過那些方式來通知 IoC Service Provider爲起提供服務的呢？
三種依賴方式：構造函數方法注入、Setter方法注入與接口注入。
構造函數方法注入：
setter方法注入：
接口注入：
參考：書籍《spring揭祕》
參考博客：https://www.cnblogs.com/weidagang2046/archive/2009/12/10/1620587.html
那麼依賴注入對象與我們自己創建對象，到底應該是一種怎樣的關係呢？
DI和對象創建誰也不能取代誰，應該根據情況採用合理的設計。那麼我們自然要問，合理的標準在哪裏呢，有沒有明確的指導方針供我們設計時參考呢？答案是有！那就是對象間關係。在OO中，對象間關係的大致可分爲兩類：縱向關係和橫向關係。縱向主要指繼承關係，比較容易區分；但橫向關係比較微妙。從本文的例子中我們已經明顯感覺到了橫向關係是需要仔細區分的。
按UML建議橫向關係大體分爲4種，它們的耦合程度由弱到強：
依賴 < 關聯 < 聚合 < 組合
1. 依賴（Dependency）：語義「a uses b」，a依賴於b，但不持有b的引用；比如：現實世界的例子有「人對空氣的依賴關係」，在程序中a.f(b)可以理解爲a對b的依賴（或者說對b的類型B的依賴），b作爲a的方法參數，a內部成員變量不引用b。
2. 關聯（Association）：語義「a has b」，a擁有b的引用，但a和b無從屬關係，二者是一種鬆散的關聯關係，可以隨時解除或建立；比如本文中「人與汽車關係」。
3. 聚合（Aggregation）：語義「a owns b」，a擁有b的引用，且有從屬關係，二者的耦合比關聯更強，但a並不負責b的生命週期。在程序中，b並非a專有的內部實現細節；除a以爲，外部也可能引用b。比如，」汽車和輪胎關係」，汽車不負責輪胎的生產，汽車報廢了輪胎或許還可以繼續使用。
4. 組合（Composition）：語義「b is a part of a」，a不僅擁有b的引用，還應該全權負責b的整個生命週期，在程序中b通常是a的內部實現細節，不暴露給外部；比如本文中人與心臟的關係。
我們注意這四種關係中有一個關鍵的概念「對象生命週期」，在建模時辨別清楚對象生命週期就不難選擇採用DI還是創建對象。DI意味着使用者不負責依賴對象的生命週期，創建對象則相反。對應到上面的4種橫向關係，我們一般可以這樣處理：第1種依賴關係不需要DI也不需要創建對象；第2，3種關聯和聚合關係適合採用DI方式，最後一種組合關係適合採用創建對象方式。
注入方式的比較我們也討論了，那麼構造函數與setter在什麼樣的情況下適合呢？
通過具體例子來體會二者的區別：「人與身份證的依賴關係」適合採用Setter注入，因爲人不是一出生就有身份證，而是到了法定年齡纔有，用構造函數注入表達的語義與此相違背。相反「人與父母的依賴關係」則適合採用構造函數注入，因爲親子關係是從人一出生就建立的，用Setter注入必然使得對象創建後有一段時間處於非法狀態，按契約式設計的術語即破壞了對象的不變量(invariant)。