Java AOP

AOP知識整理

AOP(Aspect-Oriented Programming)：面向切面的編程。OOP(Object-Oriented Programming)面向對象的編程。對于OOP我們已經再熟悉不過了，對于AOP，可能我們會覺得是一種新特性，其實AOP是對OOP的一種補充，OOP面向的是縱向編程，繼承、封裝、多態是其三大特性，而AOP是面向橫向的編程。

面向切面編程（AOP）通過提供另外一種思考程序結構的途經來彌補面向對象編程（OOP）的不足。在OOP中模塊化的關鍵單元是類（classes），而在AOP中模塊化的單元則是切面。切面能對關注點進行模塊化，例如橫切多個類型和對象的事務管理。
AOP框架是spring的一個重要組成部分。但是Spring IoC容器并不依賴于AOP，這意味著你有權利選擇是否使用AOP，AOP做為Spring IoC容器的一個補充,使它成為一個強大的中間件解決方案。

AOP在Spring Framework中的作用

• 提供聲明式企業服務，特別是為了替代EJB聲明式服務。最重要的服務是聲明性事務管理（這個我想是AOP使用最多的一處了）。
• 允許用戶實現自定義切面，用AOP來完善OOP的使用。
  

1.AOP概念：

學習AOP，當然得先了解一下其眾多的概念性術語：

• 切面（Aspect）：一個關注點的模塊化，這個關注點可能會橫切多個對象。事務管理是J2EE應用中一個關于橫切關注點的很好的例子。在Spring AOP中，切面可以使用基于模式）或者基于@Aspect注解的方式來實現。
• 連接點（Joinpoint）：在程序執行過程中某個特定的點，比如某方法調用的時候或者處理異常的時候。在Spring AOP中，一個連接點總是表示一個方法的執行。
• 通知（Advice）：在切面的某個特定的連接點上執行的動作。其中包括了“around”、“before”和“after”等不同類型的通知（通知的類型將在后面部分進行討論）。許多AOP框架（包括Spring）都是以攔截器做通知模型，并維護一個以連接點為中心的攔截器鏈。
• 切入點（Pointcut）：匹配連接點的斷言。通知和一個切入點表達式關聯，并在滿足這個切入點的連接點上運行（例如，當執行某個特定名稱的方法時）。切入點表達式如何和連接點匹配是AOP的核心：Spring缺省使用AspectJ切入點語法。
• 引入（Introduction）：用來給一個類型聲明額外的方法或屬性（也被稱為連接類型聲明（inter-type declaration））。Spring允許引入新的接口（以及一個對應的實現）到任何被代理的對象。例如，你可以使用引入來使一個bean實現IsModified接口，以便簡化緩存機制。
• 目標對象（Target Object）： 被一個或者多個切面所通知的對象。也被稱做被通知（advised）對象。 既然Spring AOP是通過運行時代理實現的，這個對象永遠是一個被代理（proxied）對象。
• AOP代理（AOP Proxy）：AOP框架創建的對象，用來實現切面契約（例如通知方法執行等等）。在Spring中，AOP代理可以是JDK動態代理或者CGLIB代理。
• 織入（Weaving）：把切面連接到其它的應用程序類型或者對象上，并創建一個被通知的對象。這些可以在編譯時（例如使用AspectJ編譯器），類加載時和運行時完成。Spring和其他純Java AOP框架一樣，在運行時完成織入。

通知類型：

• 前置通知（Before advice）：在某連接點之前執行的通知，但這個通知不能阻止連接點之前的執行流程（除非它拋出一個異常）。
• 后置通知（After returning advice）：在某連接點正常完成后執行的通知：例如，一個方法沒有拋出任何異常，正常返回。
• 異常通知（After throwing advice）：在方法拋出異常退出時執行的通知。
• 最終通知（After (finally) advice）：當某連接點退出的時候執行的通知（不論是正常返回還是異常退出）。
• 環繞通知（Around Advice）：包圍一個連接點的通知，如方法調用。這是最強大的一種通知類型。環繞通知可以在方法調用前后完成自定義的行為。它也會選擇是否繼續執行連接點或直接返回它自己的返回值或拋出異常來結束執行。
  

環繞通知是最常用的通知類型。和AspectJ一樣，Spring提供所有類型的通知，我們推薦你使用盡可能簡單的通知類型來實現需要的功能。例如，如果你只是需要一個方法的返回值來更新緩存，最好使用后置通知而不是環繞通知，盡管環繞通知也能完成同樣的事情。用最合適的通知類型可以使得編程模型變得簡單，并且能夠避免很多潛在的錯誤。比如，你不需要在JoinPoint上

調用用于環繞通知的proceed()方法，就不會有調用的問題。

在這里，基于@AspectJ的AOP我就不多寫了，因為我更青睞于Spring中使用ProxyFactoryBean創建AOP代理。

2.使用ProxyFactoryBean創建AOP代理:

在Spring里創建一個AOP代理的基本方法是使用org.springframework.aop.framework.ProxyFactoryBean。 這個類對應用的切入點和通知提供了完整的控制能力（包括它們的應用順序）。像其它的FactoryBean實現一樣，ProxyFactoryBean引入了一個間接層。如果你定義一個名為foo的ProxyFactoryBean， 引用foo的對象看到的將不是ProxyFactoryBean實例本身，而是一個ProxyFactoryBean實現里getObject() 方法所創建的對象。 這個方法將創建一個AOP代理，它包裝了一個目標對象。

ProxyFactoryBean類本身也是一個JavaBean，其屬性主要有如下用途：

• 指定你希望代理的目標對象
• 指定是否使用CGLIB。

一些主要屬性從org.springframework.aop.framework.ProxyConfig里繼承下來（這個類是Spring里所有AOP代理工廠的父類）。這些主要屬性包括：

• proxyTargetClass：這個屬性為true時，目標類本身被代理而不是目標類的接口。如果這個屬性值被設為true，CGLIB代理將被創建。
• optimize：用來控制通過CGLIB創建的代理是否使用激進的優化策略。 除非完全了解AOP代理如何處理優化，否則不推薦用戶使用這個設置。目前這個屬性僅用于CGLIB代理； 對于JDK動態代理（缺省代理）無效。
• frozen：如果一個代理配置是frozen的，就不允許對該配置進行修改。 這在簡單優化和不希望調用者在代理創建后操作代理（通過Advised接口） 時很有用。缺省值為false，即可以進行類似添加附加通知的操作。
• exposeProxy：決定當前代理是否被暴露在一個ThreadLocal 中以便被目標對象訪問。如果目標對象需要獲取代理而且exposeProxy屬性被設為 true，目標對象可以使用AopContext.currentProxy()方法。
• aopProxyFactory：使用AopProxyFactory的實現。這提供了一種方法來自定義是否使用動態代理，CGLIB或其它代理策略。 缺省實現將根據情況選擇動態代理或者CGLIB。一般情況下應該沒有使用這個屬性的需要；它是被設計來在Spring 1.1中添加新的代理類型的。
  

ProxyFactoryBean中需要說明的其它屬性包括：

• proxyInterfaces：需要代理的接口名的字符串數組。 如果沒有提供，將為目標類使用一個CGLIB代理。
• interceptorNames：Advisor的字符串數組，可以包括攔截器或其它通知的名字。 順序是很重要的，排在前面的將被優先服務。就是說列表里的第一個攔截器將能夠第一個攔截調用。

這里的名字是當前工廠中bean的名字，包括父工廠中bean的名字。這里你不能使用bean的引用因為這會導致ProxyFactoryBean忽略通知的單例設置。
你可以把一個攔截器的名字加上一個星號作為后綴（*）。這將導致這個應用程序里所有名字以星號之前部分開頭的通知器都被應用。

單例：工廠是否應該返回同一個對象，不論方法getObject()被調用的多頻繁。 多個FactoryBean實現都提供了這個方法。缺省值是true。 如果你希望使用有狀態的通知--例如，有狀態的mixin--可以把單例屬性的值設置為false來使用原型通知。

3.基于JDK和CGLIB的代理:

如果一個需要被代理的目標對象的類（后面將簡單地稱它為目標類）沒有實現任何接口，那么一個基于CGLIB的代理將被創建。 這是最簡單的場景，因為JDK代理是基于接口的，沒有接口意味著沒有使用JDK進行代理的可能.

如果ProxyFactoryBean的proxyTargetClass屬性被設為true，那么一個基于CGLIB的代理將創建。 這樣的規定是有意義的，遵循了最小驚訝法則（保證了設定的一致性）。甚至當ProxyFactoryBean的proxyInterfaces屬性被設置為一個或者多個全限定接口名， 而proxyTargetClass屬性被設置為true仍然將實際使用基于CGLIB的代理。

如果ProxyFactoryBean的proxyInterfaces屬性被設置為一個或者多個全限定接口名，一個基于JDK的代理將被創建。 被創建的代理將實現所有在proxyInterfaces屬性里被說明的接口； 如果目標類實現了全部在proxyInterfaces屬性里說明的接口以及一些額外接口，返回的代理將只實現說明的接口而不會實現那些額外接口。

如果ProxyFactoryBean的proxyInterfaces屬性沒有被設置， 但是目標類實現了一個（或者更多）接口，那么ProxyFactoryBean將自動檢測到這個目標類已經實現了至少一個接口， 一個基于JDK的代理將被創建。被實際代理的接口將是目標類所實現的全部接口； 實際上，這和在proxyInterfaces屬性中列出目標類實現的每個接口的情況是一樣的。 然而，這將顯著地減少工作量以及輸入錯誤的可能性。

 感謝閱讀，希望能幫助到大家，謝謝大家對本站的支持！