最近在看Spring5的視訊教學，學到了IOC容器這塊，對IOC有些淺薄的理解，分享一二；有錯誤之處，還請大佬指出
IOC（Inversion of Control 控制反轉），是物件導向程式設計中的一種設計原則，可以用來減低計算機程式碼之間的耦合度。什麼叫降低耦合度，大致理解就是在對程式碼進行維護升級的時候，儘量不去動原始碼，而是採用其它方式來進行功能實現，而最常用的就是利用DI（Dependency Injection 依賴注入），通過更改配置檔案的方式，來進行升級維護
在討論IOC容器之前，我們要思考，為什麼我們要解耦，先來個例子：
我們每天所使用的手機可以理解為一個Phone類例項，其中它有很多組成部分來構成，比如CPU、螢幕、喇叭等等。。。這些基礎的元素就是類中的一個個屬性，我們也可以稱之為手機的依賴，DI（依賴注入）你就可以理解為一個給屬性賦值的動作。然後具體的屬性比如螢幕，它又屬於Screen類的一個例項，它也有自己的一些屬性，比如玻璃、螢幕中間的感測器等等。這樣從大到小，每個類由好多屬性構成，每個屬性又是一個類例項，又繼續分下去，可以想象當我們要造一個最新的IPhone 13手機的時候，要為每個基礎屬性賦值（注入依賴），不斷的new例項（比如new Glass()），然後將例項作為上一層類的屬性注入，然後再重複封裝，直到最後組裝成為一個IPhone 13手機，這時候我們才造好了一個手機。如果我們還要造另外的手機IPhone 13Pro，那麼我們又要對程式碼進行大規模的改動。牽一髮（製造另外的手機）而動全身（更改手機的基本屬性）
在實際的開發過程中，其實也是在各種類例項、基本資料型別作為類的屬性，這將是一個巨大的工程，沒人敢這麼玩。
因此這時候，我們就需要解耦，怎麼解呢？這就涉及到了今天的主題：IOC容器。
IOC容器是幹嘛的呢，它其實就是解決了在實際開發過程中不用new的方式來造物件，而最常用的就是採用DI注入依賴（DI後面馬上會重新寫一個部落格再說說我的看法），最常用的就是按配置檔案來進行注入，通過DI利用反射+工廠模式，來動態的幫我們造物件，省去了上面說所的手動new的工程，在實際開發中，我們只需要對修改配置檔案（DI需要用到的），就可以完成功能的升級、完善。這樣，底層原始碼還是底層原始碼，不需要去改動，所要做的事就只是改我們的配置檔案。