IOC / AOP

IOC/AOP

標籤(空格分隔): Springspring


什麼是IoC

藉助"第三方" 實現具備依賴關係的對象之間的解耦.編程

將各個對象類封裝以後, 經過IoC容器來關聯這些對象類, 這樣對象和對象之間就經過IoC容器進行聯繫, 但對象和對象之間並無什麼直接聯繫. 這樣就作到了具備依賴關係的對象之間的解耦.設計模式

爲什麼稱爲控制反轉

軟件系統在沒有引入IoC容器以前, 對象A依賴對象B, 那麼對象A在實例化或者運行到某一點的時候, 就必須主動建立對象B或者使用已經建立好的對象B, 其中不論是建立仍是使用已經建立的對象B, 控制權都在咱們本身的受傷.
若是軟件系統引入IoC容器以後, 對象A和對象B就失去了直接聯繫, 因此對象A實例化運行以後, 若是須要對象B的話, IoC容器就會主動去建立一個對象B交給對象A去使用.框架

經過對比能夠看到對象A依賴對象B的過程由主動且須要咱們手動建立的過程, 變成被動且不須要咱們多加註意的過程. 將對象交給了IoC容器處理, 控制權顛倒過來, 這就是控制反轉.函數

依賴注入DI

所謂依賴注入,就是由IoC容器在運行期間, 動態的將某種依賴關係注入到對象之中.
依賴注入和控制反轉是從不一樣的角度描述同一件事情, 就是指經過引入IoC容器, 利用依賴注入的方式, 實現對象之間的解耦.單元測試

優勢

IoC生成對象的方式轉爲外置方式, 也就是把對象生成放在配置文件裏進行定義, 這樣, 當咱們更滑一個實現子類將會變的很簡單, 只須要修改配置文件就能夠了, 具備能夠熱插拔的特性.測試

可維護性比較好, 很是便於進行單元測試, 便於調試程序和診斷故障.設計

缺點

軟件系統中因爲引入了IoC容器, 生成對象的步驟變得複雜, 原本是二者之間的關係, 這樣就變成了三者, 在剛剛使用IoC框架的時候, 會感受系統變得不太直觀.代理

因爲IoC容器生成對象的方式是經過反射, 在運行效率上有必定的額損耗.調試


什麼是AOP

Spring AOP面向切面編程, 將日誌, 事務等相對獨立且重複的功能抽取出來, 利用Spring的配置文件或者註解的形式將這些功能織入進去, 提升複用性.

---


Spring IoC 如何實現


Bean工廠(com.springframework.beans.factory.BeanFactory): 是Spring框架中最核心的接口, 它提供了高級IoC的配置機制. BeanFactory使管理不一樣類型的Java對象成爲可能.

應用上下文(com.springframework.context.ApplicationContext):創建在BeanFactory基礎之上提供了更多面向引用的功能, 它提供了國際化支持和框架事件體系, 更加易於建立實際應用.


咱們通常稱BeanFactoryIoC容器, 而稱ApplicationContext爲應用上下文或者Spring容器.
BeanFactory是Spring框架的基礎設置, 面向Spring自己; ApplicationContext面向使用Spring框架的開發者, 幾乎全部的應用場合均可以直接使用ApplicationContext .

Spring框架是工廠, 而被建立的類對象自己也多是一個工廠, 這就造成了建立工廠的工廠.


Spring AOP

有了IOC其中CGLIB解決了靜態代理和動態代理對類的接口的依賴性和功能依賴性的問題以後, 使得將全部類(非final修飾的類)都實現代理模式成爲可能(CHLIB是基於繼承的方式作的動態代理). 因此IOC是AOP的基礎.

面向切面編程, 在咱們的應用中, 常常須要作一些事情, 可是這些事情與核心業務無關, 好比要記錄全部update的執行時間, 操做人信息等等 到日誌. 經過 AOP就能夠在不修改原有代碼的狀況下完成需求.

AOP思想: 基於動態代理把各個事務單獨抽取出來, 而後經過配置去尋找他的前置,後置,異常等方法.

實際上就是經過 [動態代理設計模式][1]的動態代理方法, 使用 InvocationHandler傳入類加載器和實現的接口 以 獲取代理運行的被代理類的函數的方法名和傳入的參數, 而後經過反射建立被代理類完成其功能, 並在其前和其後加入其它功能.

JDK動態代理類和委託類須要實現同一個接口, 也就是說只有實現了某個接口的類可使用Java動態代理機制. 可是, 事實上使用中並非遇到的全部類都會有實現接口. 所以, 對於沒有實現接口的類, 就不能使用該機制. CGLIB則能夠實現對類的動態代理.

相關文章
相關標籤/搜索