依賴註入與控制反轉 依賴註入與控制反轉是老生常談的問題。一般面試也會面試到這種問題。網上很多很多這方面的資料，搜索出來一大堆。下麵我們大話一下這些個定義。 DI依賴註入 依賴註入既依賴，又註入。依賴的是容器，註入的也是容器，把你的對象放入容器，並且依賴於容器。 IOC控制反轉 控制反轉，意思是對象的 ...
依賴註入與控制反轉
依賴註入與控制反轉是老生常談的問題。一般面試也會面試到這種問題。網上很多很多這方面的資料，搜索出來一大堆。
下麵我們大話一下這些個定義。
DI依賴註入
依賴註入既依賴，又註入。依賴的是容器，註入的也是容器，把你的對象放入容器，並且依賴於容器。
IOC控制反轉
控制反轉，意思是對象的創建由容器來確定。
在我們開始接觸編程時，一般都是通過new來創建對象。這種做法有什麼缺點呢？提高了創建對象時的耦合度、創建對象時的不統一。那麼我們如果降低耦合度、統一地創建對象呢？
通過工廠方法來創建對象可以嗎？通過工廠的確可以實現我們的目的。工廠模式，我們已經開始接觸控制反轉中的‘反轉’了。因為對象不是我們創建，都是有工廠來創建。說到反轉，其實我們在寫代碼時，有用到方法間的調用，都是使用‘反轉’。封裝都會用到反轉，下麵用白話說清楚一點。
反轉第一次聽比較難理解，其實說白了，就是原來你控制的邏輯、對象，變成交由第三方控制。如你創建了一個公共方法，提供RSA加解密。調用加密時，我們只需要提供一個鑰匙與明文就能返回一個密文，不需要知道實現的邏輯。這就是反轉，不是我們控制。
再聊聊控制反轉的進化史。
隨著對象的增多，工廠模式顯得很‘累贅’，因為每個對象都需要自己寫個方法甚至類去創建。
這時候，容器的想法出現了。用容器裝載所有的對象，需要此對象時從容器取出即可。不需要管理對象。
可以關註本人的公眾號，多年經驗的原創文章共用給大家。
