依賴倒置原則
說到 IoC（Inversion of Control，反轉控制），得先簡單說下什麼是 Dependency Inversion Principle（依賴倒置原則）。
假設我們設計一輛汽車有兩種方案：
- 方案一：先設計輪子，然後根據輪子大小設計底盤，接着根據底盤設計車身，最後根據車身設計好整個汽車。這裏就出現了一個「依賴」關係：汽車依賴車身，車身依賴底盤，底盤依賴輪子。
![在這裏插入圖片描述]()
- 方案二：我們先設計汽車的大概樣子，然後根據汽車的樣子來設計車身，根據車身來設計底盤，最後根據底盤來設計輪子。這時候，依賴關係就倒置過來了：輪子依賴底盤， 底盤依賴車身， 車身依賴汽車。
![在這裏插入圖片描述]()
在方案一中，如果說要修改輪胎設計，則會導致輪胎設計之後的流程也重新走一遍；而在方案二中，如果需要修改輪胎設計，只需要修改輪胎就行，而不需要修改其他內容。
這就是依賴倒置原則——把原本的高層建築依賴底層建築「倒置」過來，變成底層建築依賴高層建築。高層建築決定需要什麼，底層去實現這樣的需求，但是高層並不用管底層是怎麼實現的。這樣就不會出現前面的「牽一髮動全身」的情況。
兩者的關係：
以上內容來自：Spring IoC有哪些好處？
IoC
IoC（Inversion of Control，反轉控制）：在應用程序中的組件需要獲取資源時，傳統的方式是組件主動從容器中獲取所需要的資源。而在 IoC 的思想中反轉了資源的獲取方向：改由容器主動將資源推送給需要的組件，開發人員不需要知道容器是如何創建資源對象的，只需要提供接收資源的方式即可。
用找對象舉個例子：
你如果是主動找的話，你看到了一箇中意的，需要你自己去問人要聯繫方式；而如果你在婚姻介紹所（容器）呢，說了你的標準後，有關人員就會將符合你意願的另一個人的聯繫方式給你。
IoC 實現
在通過 IoC 容器讀取 Bean 的實例之前，我們需要將 IoC 容器本身實例化，在 Spring 中提供了兩種 IoC 的實現方式：
- BeanFactory：IoC 容器的基本實現，是面向 Spring 容器本身的，開發人員一般不用；
- ApplicationContext：BeanFactory 的子接口，提供了更多的特性，面向開發人員使用。
![在這裏插入圖片描述]()
ApplicationContext 的主要實現類：
- ClassPathXmlApplicationContext：基於對應類路徑下的XML格式的配置文件的實現類
- FileSystemXmlApplicationContext：基於對應文件系統中的XML格式的配置文件的實現類
- AnnotationConfigApplicationContext：基於註解配置的實現類
BeanFactory 和 ApplicationContext 的區別：
- BeanFactory 纔是 Spring 容器中的頂層接口，ApplicationContext 是它的子接口。
- 創建對象的時間點不一樣：
ApplicationContext：只要一讀取配置文件，默認情況下就會創建對象。
BeanFactory：什麼使用什麼時候創建對象
ConfigurableApplicationContext：是 ApplicationContext 的子接口，包含一些擴展方法，如 refresh() 和 close()，這兩個方法讓 ApplicationContext 有了啓動、關閉以及刷新的能力。
本質是用到了 DI（Dependency Injection，依賴注入），DI 的相關博客，敬請期待~
思考
IoC 是一種思想，而我們有時候聽到的「將 Bean 交給 Spring 的 IoC 容器管理 」這句話容易給人以「IoC 是 Spring 的容器」的假象。
挖個坑：Spring 的容器實際是一個 Map，其中存放了各種對象。