Ioc—Inversion of Control，即“控制反轉”，不是什么技術，而是一種設計思想。在Java開發中，Ioc意味着將你設計好的對象交給容器控制，而不是傳統的在你的對象內部直接控制。如何理解好Ioc呢？理解好Ioc的關鍵是要明確“誰控制誰，控制什么，為何是反轉（有反轉就應該有正轉了），哪些方面反轉了”，那我們來深入分析一下：
●誰控制誰，控制什么：傳統Java SE程序設計，我們直接在對象內部通過new進行創建對象，是程序主動去創建依賴對象；而IoC是有專門一個容器來創建這些對象，即由Ioc容器來控制對 象的創建；誰控制誰？當然是IoC 容器控制了對象；控制什么？那就是主要控制了外部資源獲取（不只是對象包括比如文件等）。
●為何是反轉，哪些方面反轉了：有反轉就有正轉，傳統應用程序是由我們自己在對象中主動控制去直接獲取依賴對象，也就是正轉；而反轉則是由容器來幫忙創建及注入依賴對象；為何是反轉？因為由容器幫我們查找及注入依賴對象，對象只是被動的接受依賴對象，所以是反轉；哪些方面反轉了？依賴對象的獲取被反轉了。
DI—Dependency Injection，即“依賴注入”：組件之間依賴關系由容器在運行期決定，形象的說，即由容器動態的將某個依賴關系注入到組件之中。依賴注入的目的並非為軟件系統帶來更多功能，而是為了提升組件重用的頻率，並為系統搭建一個靈活、可擴展的平台。通過依賴注入機制，我們只需要通過簡單的配置，而無需任何代碼就可指定目標需要的資源，完成自身的業務邏輯，而不需要關心具體的資源來自何處，由誰實現。
理解DI的關鍵是：“誰依賴誰，為什么需要依賴，誰注入誰，注入了什么”，那我們來深入分析一下：
●誰依賴於誰：當然是應用程序依賴於IoC容器；
●為什么需要依賴：應用程序需要IoC容器來提供對象需要的外部資源；
●誰注入誰：很明顯是IoC容器注入應用程序某個對象，應用程序依賴的對象；
●注入了什么：就是注入某個對象所需要的外部資源（包括對象、資源、常量數據）。
面向對象的五大基本原則
單一職責原則（SRP）
開放封閉原則（OCP）
里氏替換原則（LSP）
依賴倒置原則（DIP）
接口隔離原則（ISP）
單一職責原則（SRP）
• 一個類應該僅有一個引起它變化的原因(最簡單，最容易理解卻最不容易做到的一個設計原則)
職員類例子：
比如在職員類里，將工程師、銷售人員、銷售經理這些情況都放在職員類里考慮，其結果將會非常混亂，在這個假設下，職員類里的每個方法都要if else判斷是哪種情況，從類結構上來說將會十分臃腫，並且上述三種的職員類型，不論哪一種發生需求變化，都會改變職員類！這個是大家所不願意看到的！
開放封閉原則（OCP）
• 既開放又封閉，對擴展是開放的，對更改是封閉的！
• 擴展即擴展現行的模塊，當我們軟件的實際應用發生改變時，出現新的需求，就需要我們對模塊進行擴展，使其能夠滿足新的需求！
更改封閉即是在我們對模塊進行擴展時，勿需對源有程序代碼和DLL進行修改或重新編譯文件！
這個原則對我們在設計類的時候很有幫助，堅持這個原則就必須盡量考慮接口封裝，抽象機制和多態技術！
里氏替換原則（LSP）
• 子類可以替換父類並且出現在父類能夠出現的任何地方
• 這個原則也是在貫徹GOF倡導的面向接口編程！
在這個原則中父類應盡可能使用接口或者抽象類來實現！
子類通過實現了父類接口，能夠替父類的使用地方！
通過這個原則，我們客戶端在使用父類接口的時候，通過子類實現！
意思就是說我們依賴父類接口，在客戶端聲明一個父類接口，通過其子類來實現
這個時候就要求子類必須能夠替換父類所出現的任何地方，這樣做的好處就是，在根據新要求擴展父類接口的新子類的時候而不影響當前客戶端的使用！
依賴倒置原則（DIP）
• 傳統的結構化編程中，最上層的模塊通常都要依賴下面的子模塊來實現，也
稱為高層依賴低層！
所以DIP原則就是要逆轉這種依賴關系，讓高層模塊不要依賴低層模塊，所以稱之為依賴倒置原則！
ISP 接口隔離原則
• 這個原則的意思是：使用多個專門的接口比使用單個接口要好的多！
