這三個概念可能大家都不陌生，在面試中經常會出現關於此類的問題，關於對他們的個人理解如下。
ioc其實就是控制反轉，控制指的是物件的建立、管理、例項化權利，反轉指的是控制權交給了外部容器spring框架，打個比喻，我在專案中創造了乙個物件類，在業務層需要用到他了，一般的辦法是什麼？是不是new物件啊，畢竟程式猿最擅長new物件了，而new物件就意味著依賴性增強，那麼我不new行不行呢，這個時候ioc就出場了，ioc容器能幫助我們例項化物件並且管理它，當我們需要使⽤哪個物件，直接去問ioc容器要即可，是不是非常方便。從演化過程可以劃分成五代:第一代通過自己new物件；第二代通過使用介面來實現；第三代就轉化成bean工廠，通過工廠來建立物件；***服務中心**模式，通過註冊到服務中心然後從服務中心獲取；最後一代set注入，進行ioc容器管理
大家都知道ioc其實和di是同樣的乙個東西，既然是同乙個東西，那為什麼又會誕生他呢？di，稱之為依賴注入，他也是搞物件例項化和依賴關係維護這件事情，但是角度不同，ioc是站在物件的角度，我這個物件需要例項化，而di是站在容器的角度，容器會把物件依賴的其他物件注入。比如a物件在例項化過程中宣告了乙個b型別的屬性，就要容器把b物件注入a。
aop是oop的延續，傳統oop三大特性封裝、繼承、多型，成一種垂直繼承體系，但是存在頂級分類**重複無法優化問題，無法解決橫向切面邏輯**問題，所以就產生了aop，通過橫向抽取機制，將橫切邏輯**和業務邏輯**分離。在不改變原有業務邏輯情況下，增強橫切邏輯**，根本上解耦合，避免橫切邏輯**重複。
比如我有乙個老專案，以前就根本沒考慮到日誌列印記錄這個問題，現在需求來了，需要在所有控制層增加日誌列印，最笨的辦法就是乙個個控制層方法新增咯，或者在優化一哈，寫乙個工具類，然後再引入每乙個方法，不管怎樣，都要去動原有的**邏輯才能實現，這時候如果借助aop我們就可以實現對所有方法的攔截，通過動態**技術，實現在原方法執行前和執行後業務邏輯的增強，是不是很簡單，我甚至都不用去動原來的**就實現了這個需求，這就是aop。
Spring IOC容器和DI依賴注入
inversion of control 控制反轉容器。作用 解決物件建立以及管理問題。解析 傳統關於物件建立 user user new user 自己控制物件的建立，自己宣告變數管理物件引用。ioc 需要物件，自己不建立，交給ioc容器建立並管理，需要的時候從ioc容器中獲取即可，這種情況就叫控...
有關springIOC 和DI自己的理解
在傳統開發中，我們需要進行分層開發web service 持久層，我們在web層通常需要乙個service服務通常是 在web層 uerservice userservice new userserviceimpl 折讓最然能夠在web層使用service層物件，但是會在程式中將 寫死，不利於後期的...
學習Spring IOC控制反轉和DI依賴注入總結
30歲的小曹，20歲的身體，還在堅持在能力允許控制範圍內22點睡覺，5點起床鍛鍊身體，好好學習，除了加班或者像今天這樣的深夜，再一次寫已經有x百萬人寫過的 spring ioc 的總結部落格。一 ioc 控制反轉詳解 1 傳統非spring管理時候的物件間呼叫依賴 我們都知道，隨便一本破框架的破書上...