IOC的理解（轉載）

轉載自：https://www.zhihu.com/question/23277575/answer/169698662

要了解控制反轉( Inversion of Control ), 我以爲有必要先了解軟件設計的一個重要思想：依賴倒置原則（Dependency Inversion Principle ）。

什麼是依賴倒置原則？假設咱們設計一輛汽車：先設計輪子，而後根據輪子大小設計底盤，接着根據底盤設計車身，最後根據車身設計好整個汽車。這裏就出現了一個「依賴」關係：汽車依賴車身，車身依賴底盤，底盤依賴輪子。

這樣的設計看起來沒問題，可是可維護性卻很低。假設設計完工以後，上司卻忽然說根據市場需求的變更，要咱們把車子的輪子設計都改大一碼。這下咱們就蛋疼了：由於咱們是根據輪子的尺寸設計的底盤，輪子的尺寸一改，底盤的設計就得修改；一樣由於咱們是根據底盤設計的車身，那麼車身也得改，同理汽車設計也得改——整個設計幾乎都得改！

咱們如今換一種思路。咱們先設計汽車的大概樣子，而後根據汽車的樣子來設計車身，根據車身來設計底盤，最後根據底盤來設計輪子。這時候，依賴關係就倒置過來了：輪子依賴底盤， 底盤依賴車身， 車身依賴汽車。

這時候，上司再說要改動輪子的設計，咱們就只須要改動輪子的設計，而不須要動底盤，車身，汽車的設計了。

這就是依賴倒置原則——把本來的高層建築依賴底層建築「倒置」過來，變成底層建築依賴高層建築。高層建築決定須要什麼，底層去實現這樣的需求，可是高層並不用管底層是怎麼實現的。這樣就不會出現前面的「牽一髮動全身」的狀況。

控制反轉（Inversion of Control） 就是依賴倒置原則的一種代碼設計的思路。具體採用的方法就是所謂的依賴注入（Dependency Injection）。其實這些概念初次接觸都會感到雲裏霧裏的。說穿了，這幾種概念的關係大概以下：

爲了理解這幾個概念，咱們仍是用上面汽車的例子。只不過此次換成代碼。咱們先定義四個Class，車，車身，底盤，輪胎。而後初始化這輛車，最後跑這輛車。代碼結構以下：

這樣，就至關於上面第一個例子，上層建築依賴下層建築——每個類的構造函數都直接調用了底層代碼的構造函數。假設咱們須要改動一下輪胎（Tire）類，把它的尺寸變成動態的，而不是一直都是30。咱們須要這樣改：

因爲咱們修改了輪胎的定義，爲了讓整個程序正常運行，咱們須要作如下改動：

由此咱們能夠看到，僅僅是爲了修改輪胎的構造函數，這種設計卻須要修改整個上層全部類的構造函數！在軟件工程中，這樣的設計幾乎是不可維護的——在實際工程項目中，有的類可能會是幾千個類的底層，若是每次修改這個類，咱們都要修改全部以它做爲依賴的類，那軟件的維護成本就過高了。

因此咱們須要進行控制反轉（IoC），及上層控制下層，而不是下層控制着上層。咱們用依賴注入（Dependency Injection）這種方式來實現控制反轉。所謂依賴注入，就是把底層類做爲參數傳入上層類，實現上層類對下層類的「控制」。這裏咱們用構造方法傳遞的依賴注入方式從新寫車類的定義：

這裏咱們再把輪胎尺寸變成動態的，一樣爲了讓整個系統順利運行，咱們須要作以下修改：

看到沒？這裏我只須要修改輪胎類就好了，不用修改其餘任何上層類。這顯然是更容易維護的代碼。不只如此，在實際的工程中，這種設計模式還有利於不一樣組的協同合做和單元測試：好比開發這四個類的分別是四個不一樣的組，那麼只要定義好了接口，四個不一樣的組能夠同時進行開發而不相互受限制；而對於單元測試，若是咱們要寫Car類的單元測試，就只須要Mock一下Framework類傳入Car就好了，而不用把Framework, Bottom, Tire所有new一遍再來構造Car。

這裏咱們是採用的構造函數傳入的方式進行的依賴注入。其實還有另外兩種方法：Setter傳遞和接口傳遞。這裏就很少講了，核心思路都是同樣的，都是爲了實現控制反轉。

 

看到這裏你應該能理解什麼控制反轉和依賴注入了。那什麼是控制反轉容器(IoC Container)呢？其實上面的例子中，對車類進行初始化的那段代碼發生的地方，就是控制反轉容器。

顯然你也應該觀察到了，由於採用了依賴注入，在初始化的過程當中就不可避免的會寫大量的new。這裏IoC容器就解決了這個問題。這個容器能夠自動對你的代碼進行初始化，你只須要維護一個Configuration（能夠是xml能夠是一段代碼），而不用每次初始化一輛車都要親手去寫那一大段初始化的代碼。這是引入IoC Container的第一個好處。

IoC Container的第二個好處是：咱們在建立實例的時候不須要了解其中的細節。在上面的例子中，咱們本身手動建立一個車instance時候，是從底層往上層new的：

這個過程當中，咱們須要瞭解整個Car/Framework/Bottom/Tire類構造函數是怎麼定義的，才能一步一步new/注入。

而IoC Container在進行這個工做的時候是反過來的，它先從最上層開始往下找依賴關係，到達最底層以後再往上一步一步new（有點像深度優先遍歷）：

這裏IoC Container能夠直接隱藏具體的建立實例的細節，在咱們來看它就像一個工廠：

咱們就像是工廠的客戶。咱們只須要向工廠請求一個Car實例，而後它就給咱們按照Config建立了一個Car實例。咱們徹底不用管這個Car實例是怎麼一步一步被建立出來。

實際項目中，有的Service Class多是十年前寫的，有幾百個類做爲它的底層。假設咱們新寫的一個API須要實例化這個Service，咱們總不可能回頭去搞清楚這幾百個類的構造函數吧？IoC Container的這個特性就很完美的解決了這類問題——由於這個架構要求你在寫class的時候須要寫相應的Config文件，因此你要初始化好久之前的Service類的時候，前人都已經寫好了Config文件，你直接在須要用的地方注入這個Service就能夠了。這大大增長了項目的可維護性且下降了開發難度。