AOP（Aspect Orient Programming），作爲面向對象編程的一種補充，廣泛應用於處理一些具有橫切性質的系統級服務，如事務管理、安全檢查、緩存、對象池管理等。AOP 實現的關鍵就在於 AOP 框架自動創建的 AOP 代理，AOP 代理則可分爲靜態代理和動態代理兩大類，其中靜態代理是指使用 AOP 框架提供的命令進行編譯，從而在編譯階段就可生成 AOP 代理類，因此也稱爲編譯時增強；而動態代理則在運行時藉助於 JDK 動態代理、CGLIB 等在內存中“臨時”生成 AOP 動態代理類，因此也被稱爲運行時增強。
在傳統 OOP 編程裏以對象爲核心，整個軟件系統由系列相互依賴的對象所組成，而這些對象將被抽象成一個一個的類，並允許使用類繼承來管理類與類之間一般到特殊的關係。隨着軟件規模的增大，應用的逐漸升級，慢慢出現了一些 OOP 很難解決的問題。
我們可以通過分析、抽象出一系列具有一定屬性與行爲的對象，並通過這些對象之間的協作來形成一個完整的軟件功能。由於對象可以繼承，因此我們可以把具有相同功能或相同特性的屬性抽象到一個層次分明的類結構體系中。隨着軟件規範的不斷擴大，專業化分工越來越系列，以及 OOP 應用實踐的不斷增多，隨之也暴露出了一些 OOP 無法很好解決的問題。
現在假設系統中有 3 段完全相似的代碼，這些代碼通常會採用“複製”、“粘貼”方式來完成，通過這種“複製”、“粘貼”方式開發出來的軟件如圖 1 所示。
圖 1.多個地方包含相同代碼的軟件
看到如圖 1 所示的示意圖，可能有的讀者已經發現了這種做法的不足之處：如果有一天，圖 1 中的深色代碼段需要修改，那是不是要打開 3 個地方的代碼進行修改？如果不是 3 個地方包含這段代碼，而是 100 個地方，甚至是 1000 個地方包含這段代碼段，那會是什麼後果？
爲了解決這個問題，我們通常會採用將如圖 1 所示的深色代碼部分定義成一個方法，然後在 3 個代碼段中分別調用該方法即可。在這種方式下，軟件系統的結構如圖 2 所示。
圖 2 通過方法調用實現系統功能
對於如圖 2 所示的軟件系統，如果需要修改深色部分的代碼，只要修改一個地方即可，不管整個系統中有多少地方調用了該方法，程序無須修改這些地方，只需修改被調用的方法即可——通過這種方式，大大降低了軟件後期維護的複雜度。
對於如圖 2 所示的方法 1、方法 2、方法 3 依然需要顯式調用深色方法，這樣做能夠解決大部分應用場景。但對於一些更特殊的情況：應用需要方法 1、方法 2、方法 3 徹底與深色方法分離——方法 1、方法 2、方法 3 無須直接調用深色方法，那如何解決？
因爲軟件系統需求變更是很頻繁的事情，系統前期設計方法 1、方法 2、方法 3 時只實現了核心業務功能，過了一段時間，我們需要爲方法 1、方法 2、方法 3 都增加事務控制；又過了一段時間，客戶提出方法 1、方法 2、方法 3 需要進行用戶合法性驗證，只有合法的用戶才能執行這些方法；又過了一段時間，客戶又提出方法 1、方法 2、方法 3 應該增加日誌記錄；又過了一段時間，客戶又提出……面對這樣的情況，我們怎麼辦？通常有兩種做法：
- 根據需求說明書，直接拒絕客戶要求。
- 擁抱需求，滿足客戶的需求。
第一種做法顯然不好，客戶是上帝，我們應該儘量滿足客戶的需求。通常會採用第二種做法，那如何解決呢？是不是每次先定義一個新方法，然後修改方法 1、方法 2、方法 3，增加調用新方法？這樣做的工作量也不小啊！我們希望有一種特殊的方法：我們只要定義該方法，無須在方法 1、方法 2、方法 3 中顯式調用它，系統會“自動”執行該特殊方法。
上面想法聽起來很神奇，甚至有一些不切實際，但其實是完全可以實現的，實現這個需求的技術就是 AOP。AOP 專門用於處理系統中分佈於各個模塊（不同方法）中的交叉關注點的問題，在 Java EE 應用中，常常通過 AOP 來處理一些具有橫切性質的系統級服務，如事務管理、安全檢查、緩存、對象池管理等，AOP 已經成爲一種非常常用的解決方案。
AspectJ 是一個基於 Java 語言的 AOP 框架，提供了強大的 AOP 功能，其他很多 AOP 框架都借鑑或採納其中的一些思想。
AspectJ 是 Java 語言的一個 AOP 實現，其主要包括兩個部分：第一個部分定義瞭如何表達、定義 AOP 編程中的語法規範，通過這套語言規範，我們可以方便地用 AOP 來解決 Java 語言中存在的交叉關注點問題；另一個部分是工具部分，包括編譯器、調試工具等。
AspectJ 是最早、功能比較強大的 AOP 實現之一，對整套 AOP 機制都有較好的實現，很多其他語言的 AOP 實現，也借鑑或採納了 AspectJ 中很多設計。在 Java 領域，AspectJ 中的很多語法結構基本上已成爲 AOP 領域的標準。
下載、安裝 AspectJ 比較簡單，讀者登錄 AspectJ 官網（http://www.eclipse.org/aspectj），即可下載到一個可執行的 JAR 包，使用 java -jar aspectj-1.x.x.jar 命令、多次單擊“Next”按鈕即可成功安裝 AspectJ。
成功安裝了 AspectJ 之後，將會在 E:\Java\AOP\aspectj1.6 路徑下（AspectJ 的安裝路徑）看到如下文件結構：
- bin：該路徑下存放了 aj、aj5、ajc、ajdoc、ajbrowser 等命令，其中 ajc 命令最常用，它的作用類似於 javac，用於對普通 Java 類進行編譯時增強。
- docs：該路徑下存放了 AspectJ 的使用說明、參考手冊、API 文檔等文檔。
- lib：該路徑下的 4 個 JAR 文件是 AspectJ 的核心類庫。
- 相關授權文件。
一些文檔、AspectJ 入門書籍，一談到使用 AspectJ，就認爲必須使用 Eclipse 工具，似乎離開了該工具就無法使用 AspectJ 了。
雖然 AspectJ 是 Eclipse 基金組織的開源項目，而且提供了 Eclipse 的 AJDT 插件（AspectJ Development Tools）來開發 AspectJ 應用，但 AspectJ 絕對無須依賴於 Eclipse 工具。
實際上，AspectJ 的用法非常簡單，就像我們使用 JDK 編譯、運行 Java 程序一樣。下面通過一個簡單的程序來示範 AspectJ 的用法，並分析 AspectJ 如何在編譯時進行增強。
首先編寫一個簡單的 Java 類，這個 Java 類用於模擬一個業務組件。
清單 1.Hello.java
public class Hello
{
// 定義一個簡單方法，模擬應用中的業務邏輯方法
public void sayHello()
{
System.out.println("Hello AspectJ!");
}
// 主方法，程序的入口
public static void main(String[] args)
{
Hello h = new Hello();
h.sayHello();
}
}
|
上面 Hello 類模擬了一個業務邏輯組件，編譯、運行該 Java 程序，這個結果是沒有任何懸念的，程序將在控制檯打印“Hello AspectJ”字符串。
假設現在客戶需要在執行 sayHello() 方法之前啓動事務，當該方法執行結束時關閉事務，在傳統編程模式下，我們必須手動修改 sayHello() 方法——如果改爲使用 AspectJ，則可以無須修改上面的 sayHello() 方法。
下面我們定義一個特殊的 Java 類。
清單 2.TxAspect.java
public aspect TxAspect
{
// 指定執行 Hello.sayHello() 方法時執行下面代碼塊
void around():call(void Hello.sayHello())
{
System.out.println("開始事務 ...");
proceed();
System.out.println("事務結束 ...");
}
}
|
可能讀者已經發現了，上面類文件中不是使用 class、interface、enum 在定義 Java 類，而是使用了 aspect ——難道 Java 語言又新增了關鍵字？沒有！上面的 TxAspect 根本不是一個 Java 類，所以 aspect 也不是 Java 支持的關鍵字，它只是 AspectJ 才能識別的關鍵字。
上面粗體字代碼也不是方法，它只是指定當程序執行 Hello 對象的 sayHello() 方法時，系統將改爲執行粗體字代碼的花括號代碼塊，其中 proceed() 代表回調原來的 sayHello() 方法。
正如前面提到的，Java 無法識別 TxAspect.java 文件的內容，所以我們要使用 ajc.exe 命令來編譯上面的 Java 程序。爲了能在命令行使用 ajc.exe 命令，需要把 AspectJ 安裝目錄下的 bin 路徑（比如 E:\Java\AOP\aspectj1.6\bin 目錄）添加到系統的 PATH 環境變量中。接下來執行如下命令進行編譯：
ajc -d . Hello.java TxAspect.java
我們可以把 ajc.exe 理解成 javac.exe 命令，都用於編譯 Java 程序，區別是 ajc.exe 命令可識別 AspectJ 的語法；從這個意義上看，我們可以將 ajc.exe 當成一個增強版的 javac.exe 命令。
運行該 Hello 類依然無須任何改變，因爲 Hello 類位於 lee 包下。程序使用如下命令運行 Hello 類：
java lee.Hello
運行該程序，將看到一個令人驚喜的結果：
開始事務 ...
Hello AspectJ!
事務結束 ...
從上面運行結果來看，我們完全可以不對 Hello.java 類進行任何修改，同時又可以滿足客戶的需求：上面程序只是在控制檯打印“開始事務 ...”、“結束事務 ...”來模擬了事務操作，實際上我們可用實際的事務操作代碼來代替這兩行簡單的語句，這就可以滿足客戶需求了。
如果客戶再次提出新需求，需要在 sayHello() 方法後增加記錄日誌的功能，那也很簡單，我們再定義一個 LogAspect，程序如下：
清單 3.LogAspect.java
public aspect LogAspect
{
// 定義一個 PointCut，其名爲 logPointcut
// 該 PointCut 對應於指定 Hello 對象的 sayHello 方法
pointcut logPointcut()
:execution(void Hello.sayHello());
// 在 logPointcut 之後執行下面代碼塊
after():logPointcut()
{
System.out.println("記錄日誌 ...");
}
}
|
上面程序的粗體字代碼定義了一個 Pointcut：logPointcut - 等同於執行 Hello 對象的 sayHello() 方法，並指定在 logPointcut 之後執行簡單的代碼塊，也就是說，在 sayHello() 方法之後執行指定代碼塊。使用如下命令來編譯上面的 Java 程序：
ajc -d . *.java
再次運行 Hello 類，將看到如下運行結果：
開始事務 ...
Hello AspectJ!
記錄日誌 ...
事務結束 ...
從上面運行結果來看，通過使用 AspectJ 提供的 AOP 支持，我們可以爲 sayHello() 方法不斷增加新功能。
爲什麼在對 Hello 類沒有任何修改的前提下，而 Hello 類能不斷地、動態增加新功能呢？這看上去並不符合 Java 基本語法規則啊。實際上我們可以使用 Java 的反編譯工具來反編譯前面程序生成的 Hello.class 文件，發現 Hello.class 文件的代碼如下：
清單 4.Hello.class
package lee;
import java.io.PrintStream;
import org.aspectj.runtime.internal.AroundClosure;
public class Hello
{
public void sayHello()
{
try
{
System.out.println("Hello AspectJ!"); } catch (Throwable localThrowable) {
LogAspect.aspectOf().ajc$after$lee_LogAspect$1$9fd5dd97(); throw localThrowable; }
LogAspect.aspectOf().ajc$after$lee_LogAspect$1$9fd5dd97();
}
...
private static final void sayHello_aroundBody1$advice(Hello target,
TxAspect ajc$aspectInstance, AroundClosure ajc$aroundClosure)
{
System.out.println("開始事務 ...");
AroundClosure localAroundClosure = ajc$aroundClosure; sayHello_aroundBody0(target);
System.out.println("事務結束 ...");
}
}
|
不難發現這個 Hello.class 文件不是由原來的 Hello.java 文件編譯得到的，該 Hello.class 裏新增了很多內容——這表明 AspectJ 在編譯時“自動”編譯得到了一個新類，這個新類增強了原有的 Hello.java 類的功能，因此 AspectJ 通常被稱爲編譯時增強的 AOP 框架。
提示：與 AspectJ 相對的還有另外一種 AOP 框架，它們不需要在編譯時對目標類進行增強，而是運行時生成目標類的代理類，該代理類要麼與目標類實現相同的接口，要麼是目標類的子類——總之，代理類的實例可作爲目標類的實例來使用。一般來說，編譯時增強的 AOP 框架在性能上更有優勢——因爲運行時動態增強的 AOP 框架需要每次運行時都進行動態增強。
實際上，AspectJ 允許同時爲多個方法添加新功能，只要我們定義 Pointcut 時指定匹配更多的方法即可。如下片段：
pointcut xxxPointcut() :execution(void H*.say*()); |
上面程序中的 xxxPointcut 將可以匹配所有以 H 開頭的類中、所有以 say 開頭的方法，但該方法返回的必須是 void；如果不想匹配任意的返回值類型，則可將代碼改爲如下形式：
pointcut xxxPointcut()
:execution(* H*.say*());
關於如何定義 AspectJ 中的 Aspect、Pointcut 等，讀者可以參考 AspectJ 安裝路徑下的 doc 目錄裏的 quick5.pdf 文件。
與 AspectJ 相同的是，Spring AOP 同樣需要對目標類進行增強，也就是生成新的 AOP 代理類；與 AspectJ 不同的是，Spring AOP 無需使用任何特殊命令對 Java 源代碼進行編譯，它採用運行時動態地、在內存中臨時生成“代理類”的方式來生成 AOP 代理。
Spring 允許使用 AspectJ Annotation 用於定義方面（Aspect）、切入點（Pointcut）和增強處理（Advice），Spring 框架則可識別並根據這些 Annotation 來生成 AOP 代理。Spring 只是使用了和 AspectJ 5 一樣的註解，但並沒有使用 AspectJ 的編譯器或者織入器（Weaver），底層依然使用的是 Spring AOP，依然是在運行時動態生成 AOP 代理，並不依賴於 AspectJ 的編譯器或者織入器。
簡單地說，Spring 依然採用運行時生成動態代理的方式來增強目標對象，所以它不需要增加額外的編譯，也不需要 AspectJ 的織入器支持；而 AspectJ 在採用編譯時增強，所以 AspectJ 需要使用自己的編譯器來編譯 Java 文件，還需要織入器。
爲了啓用 Spring 對 @AspectJ 方面配置的支持，並保證 Spring 容器中的目標 Bean 被一個或多個方面自動增強，必須在 Spring 配置文件中配置如下片段：
<?xml version="1.0" encoding="GBK"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:aop="http://www.springframework.org/schema/aop" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-3.0.xsd"> <!-- 啓動 @AspectJ 支持 --> <aop:aspectj-autoproxy/> </beans> |
當然，如果我們希望完全啓動 Spring 的“零配置”功能，則還需要啓用 Spring 的“零配置”支持，讓 Spring 自動搜索指定路徑下 Bean 類。
所謂自動增強，指的是 Spring 會判斷一個或多個方面是否需要對指定 Bean 進行增強，並據此自動生成相應的代理，從而使得增強處理在合適的時候被調用。
如果不打算使用 Spring 的 XML Schema 配置方式，則應該在 Spring 配置文件中增加如下片段來啓用 @AspectJ 支持。
<!-- 啓動 @AspectJ 支持 --> <bean class="org.springframework.aop.aspectj.annotation. AnnotationAwareAspectJAutoProxyCreator"/> |
上面配置文件中的 AnnotationAwareAspectJAutoProxyCreator 是一個 Bean 後處理器（BeanPostProcessor），該 Bean 後處理器將會爲容器中 Bean 生成 AOP 代理，
當啓動了 @AspectJ 支持後，只要我們在 Spring 容器中配置一個帶 @Aspect 註釋的 Bean，Spring 將會自動識別該 Bean，並將該 Bean 作爲方面 Bean 處理。
在 Spring 容器中配置方面 Bean（即帶 @Aspect 註釋的 Bean），與配置普通 Bean 沒有任何區別，一樣使用 <bean.../> 元素進行配置，一樣支持使用依賴注入來配置屬性值；如果我們啓動了 Spring 的“零配置”特性，一樣可以讓 Spring 自動搜索，並裝載指定路徑下的方面 Bean。
使用 @Aspect 標註一個 Java 類，該 Java 類將會作爲方面 Bean，如下面代碼片段所示：
// 使用 @Aspect 定義一個方面類
@Aspect
public class LogAspect
{
// 定義該類的其他內容
...
}
|
方面類（用 @Aspect 修飾的類）和其他類一樣可以有方法、屬性定義，還可能包括切入點、增強處理定義。
當我們使用 @Aspect 來修飾一個 Java 類之後，Spring 將不會把該 Bean 當成組件 Bean 處理，因此負責自動增強的後處理 Bean 將會略過該 Bean，不會對該 Bean 進行任何增強處理。
開發時無須擔心使用 @Aspect 定義的方面類被增強處理，當 Spring 容器檢測到某個 Bean 類使用了 @Aspect 標註之後，Spring 容器不會對該 Bean 類進行增強。
下面將會考慮採用 Spring AOP 來改寫前面介紹的例子：
下面例子使用一個簡單的 Chinese 類來模擬業務邏輯組件：
清單 5.Chinese.java
@Component
public class Chinese
{
// 實現 Person 接口的 sayHello() 方法
public String sayHello(String name)
{
System.out.println("-- 正在執行 sayHello 方法 --");
// 返回簡單的字符串
return name + " Hello , Spring AOP";
}
// 定義一個 eat() 方法
public void eat(String food)
{
System.out.println("我正在吃 :"+ food);
}
}
|
提供了上面 Chinese 類之後，接下來假設同樣需要爲上面 Chinese 類的每個方法增加事務控制、日誌記錄，此時可以考慮使用 Around、AfterReturning 兩種增強處理。
先看 AfterReturning 增強處理代碼。
清單 6.AfterReturningAdviceTest.java
// 定義一個方面
@Aspect
public class AfterReturningAdviceTest
{
// 匹配 org.crazyit.app.service.impl 包下所有類的、
// 所有方法的執行作爲切入點
@AfterReturning(returning="rvt",
pointcut="execution(* org.crazyit.app.service.impl.*.*(..))")
public void log(Object rvt)
{
System.out.println("獲取目標方法返回值 :" + rvt);
System.out.println("模擬記錄日誌功能 ...");
}
}
|
上面 Aspect 類使用了 @Aspect 修飾，這樣 Spring 會將它當成一個方面 Bean 進行處理。其中程序中粗體字代碼指定將會在調用 org.crazyit.app.service.impl 包下的所有類的所有方法之後織入 log(Object rvt) 方法。
再看 Around 增強處理代碼：
清單 7.AfterReturningAdviceTest.java
// 定義一個方面
@Aspect
public class AroundAdviceTest
{
// 匹配 org.crazyit.app.service.impl 包下所有類的、
// 所有方法的執行作爲切入點
@Around("execution(* org.crazyit.app.service.impl.*.*(..))")
public Object processTx(ProceedingJoinPoint jp)
throws java.lang.Throwable
{
System.out.println("執行目標方法之前，模擬開始事務 ...");
// 執行目標方法，並保存目標方法執行後的返回值
Object rvt = jp.proceed(new String[]{"被改變的參數"});
System.out.println("執行目標方法之後，模擬結束事務 ...");
return rvt + " 新增的內容";
}
}
|
與前面的 AfterReturning 增強處理類似的，此處同樣使用了 @Aspect 來修飾前面 Bean，其中粗體字代碼指定在調用 org.crazyit.app.service.impl 包下的所有類的所有方法的“前後（Around）” 織入 processTx(ProceedingJoinPoint jp) 方法
需要指出的是，雖然此處只介紹了 Spring AOP 的 AfterReturning、Around 兩種增強處理，但實際上 Spring 還支持 Before、After、AfterThrowing 等增強處理，關於 Spring AOP 編程更多、更細緻的編程細節，可以參考《輕量級 Java EE 企業應用實戰》一書。
本示例採用了 Spring 的零配置來開啓 Spring AOP，因此上面 Chinese 類使用了 @Component 修飾，而方面 Bean 則使用了 @Aspect 修飾，方面 Bean 中的 Advice 則分別使用了 @AfterReturning、@Around 修飾。接下來只要爲 Spring 提供如下配置文件即可：
清單 8.bean.xml
<?xml version="1.0" encoding="GBK"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:context="http://www.springframework.org/schema/context" xmlns:aop="http://www.springframework.org/schema/aop" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-3.0.xsd"> <!-- 指定自動搜索 Bean 組件、自動搜索方面類 --> <context:component-scan base-package="org.crazyit.app.service ,org.crazyit.app.advice"> <context:include-filter type="annotation" expression="org.aspectj.lang.annotation.Aspect"/> </context:component-scan> <!-- 啓動 @AspectJ 支持 --> <aop:aspectj-autoproxy/> </beans> |
接下來按傳統方式來獲取 Spring 容器中 chinese Bean、並調用該 Bean 的兩個方法，程序代碼如下：
清單 9.BeanTest.java
public class BeanTest
{
public static void main(String[] args)
{
// 創建 Spring 容器
ApplicationContext ctx = new
ClassPathXmlApplicationContext("bean.xml");
Chinese p = ctx.getBean("chinese" ,Chinese.class);
System.out.println(p.sayHello("張三"));
p.eat("西瓜");
}
}
|
從上面開發過程可以看出，對於 Spring AOP 而言，開發者提供的業務組件、方面 Bean 並沒有任何特別的地方。只是方面 Bean 需要使用 @Aspect 修飾即可。程序不需要使用特別的編譯器、織入器進行處理。
運行上面程序，將可以看到如下執行結果：
執行目標方法之前，模擬開始事務 ...
-- 正在執行 sayHello 方法 --
執行目標方法之後，模擬結束事務 ...
獲取目標方法返回值 : 被改變的參數 Hello , Spring AOP 新增的內容
模擬記錄日誌功能 ...
被改變的參數 Hello , Spring AOP 新增的內容
執行目標方法之前，模擬開始事務 ...
我正在吃 : 被改變的參數
執行目標方法之後，模擬結束事務 ...
獲取目標方法返回值 :null 新增的內容
模擬記錄日誌功能 ...
雖然程序是在調用 Chinese 對象的 sayHello、eat 兩個方法，但從上面運行結果不難看出：實際執行的絕對不是 Chinese 對象的方法，而是 AOP 代理的方法。也就是說，Spring AOP 同樣爲 Chinese 類生成了 AOP 代理類。這一點可通過在程序中增加如下代碼看出：
System.out.println(p.getClass());
上面代碼可以輸出 p 變量所引用對象的實現類，再次執行程序將可以看到上面代碼產生 class org.crazyit.app.service.impl.Chinese$$EnhancerByCGLIB$$290441d2 的輸出，這纔是 p 變量所引用的對象的實現類，這個類也就是 Spring AOP 動態生成的 AOP 代理類。從 AOP 代理類的類名可以看出，AOP 代理類是由 CGLIB 來生成的。
如果將上面程序程序稍作修改：只要讓上面業務邏輯類 Chinese 類實現一個任意接口——這種做法更符合 Spring 所倡導的“面向接口編程”的原則。假設程序爲 Chinese 類提供如下 Person 接口，並讓 Chinese 類實現該接口：
清單 10.Person.java
public interface Person
{
String sayHello(String name);
void eat(String food);
}
|
接下來讓 BeanTest 類面向 Person 接口、而不是 Chinese 類編程。即將 BeanTest 類改爲如下形式：
清單 11.BeanTest.java
public class BeanTest
{
public static void main(String[] args)
{
// 創建 Spring 容器
ApplicationContext ctx = new
ClassPathXmlApplicationContext("bean.xml");
Person p = ctx.getBean("chinese" ,Person.class);
System.out.println(p.sayHello("張三"));
p.eat("西瓜");
System.out.println(p.getClass());
}
}
|
原來的程序是將面向 Chinese 類編程，現在將該程序改爲面向 Person 接口編程，再次運行該程序，程序運行結果沒有發生改變。只是 System.out.println(p.getClass()); 將會輸出 class $Proxy7，這說明此時的 AOP 代理並不是由 CGLIB 生成的，而是由 JDK 動態代理生成的。
Spring AOP 框架對 AOP 代理類的處理原則是：如果目標對象的實現類實現了接口，Spring AOP 將會採用 JDK 動態代理來生成 AOP 代理類；如果目標對象的實現類沒有實現接口，Spring AOP 將會採用 CGLIB 來生成 AOP 代理類——不過這個選擇過程對開發者完全透明、開發者也無需關心。
Spring AOP 會動態選擇使用 JDK 動態代理、CGLIB 來生成 AOP 代理，如果目標類實現了接口，Spring AOP 則無需 CGLIB 的支持，直接使用 JDK 提供的 Proxy 和 InvocationHandler 來生成 AOP 代理即可。關於如何 Proxy 和 InvocationHandler 來生成動態代理不在本文介紹範圍之內，如果讀者對 Proxy 和 InvocationHandler 的用法感興趣則可自行參考 Java API 文檔或《瘋狂 Java 講義》。
通過前面介紹可以知道：AOP 代理其實是由 AOP 框架動態生成的一個對象，該對象可作爲目標對象使用。AOP 代理包含了目標對象的全部方法，但 AOP 代理中的方法與目標對象的方法存在差異：AOP 方法在特定切入點添加了增強處理，並回調了目標對象的方法。
AOP 代理所包含的方法與目標對象的方法示意圖如圖 3 所示。
圖 3.AOP 代理的方法與目標對象的方法
Spring 的 AOP 代理由 Spring 的 IoC 容器負責生成、管理，其依賴關係也由 IoC 容器負責管理。因此，AOP 代理可以直接使用容器中的其他 Bean 實例作爲目標，這種關係可由 IoC 容器的依賴注入提供。
縱觀 AOP 編程，其中需要程序員參與的只有 3 個部分：
- 定義普通業務組件。
- 定義切入點，一個切入點可能橫切多個業務組件。
- 定義增強處理，增強處理就是在 AOP 框架爲普通業務組件織入的處理動作。
上面 3 個部分的第一個部分是最平常不過的事情，無須額外說明。那麼進行 AOP 編程的關鍵就是定義切入點和定義增強處理。一旦定義了合適的切入點和增強處理，AOP 框架將會自動生成 AOP 代理，而 AOP 代理的方法大致有如下公式：
代理對象的方法 = 增強處理 + 被代理對象的方法
在上面這個業務定義中，不難發現 Spring AOP 的實現原理其實很簡單：AOP 框架負責動態地生成 AOP 代理類，這個代理類的方法則由 Advice 和回調目標對象的方法所組成。
對於前面提到的圖 2 所示的軟件調用結構：當方法 1、方法 2、方法 3 ……都需要去調用某個具有“橫切”性質的方法時，傳統的做法是程序員去手動修改方法 1、方法 2、方法 3 ……、通過代碼來調用這個具有“橫切”性質的方法，但這種做法的可擴展性不好，因爲每次都要改代碼。
於是 AOP 框架出現了，AOP 框架則可以“動態的”生成一個新的代理類，而這個代理類所包含的方法 1、方法 2、方法 3 ……也增加了調用這個具有“橫切”性質的方法——但這種調用由 AOP 框架自動生成的代理類來負責，因此具有了極好的擴展性。程序員無需手動修改方法 1、方法 2、方法 3 的代碼，程序員只要定義切入點即可—— AOP 框架所生成的 AOP 代理類中包含了新的方法 1、訪法 2、方法 3，而 AOP 框架會根據切入點來決定是否要在方法 1、方法 2、方法 3 中回調具有“橫切”性質的方法。
簡而言之：AOP 原理的奧妙就在於動態地生成了代理類，這個代理類實現了圖 2 的調用——這種調用無需程序員修改代碼。接下來介紹的 CGLIB 就是一個代理生成庫，下面介紹如何使用 CGLIB 來生成代理類。
CGLIB（Code Generation Library），簡單來說，就是一個代碼生成類庫。它可以在運行時候動態是生成某個類的子類。
此處使用前面定義的 Chinese 類，現在改爲直接使用 CGLIB 來生成代理，這個代理類同樣可以實現 Spring AOP 代理所達到的效果。
下面先爲 CGLIB 提供一個攔截器實現類：
清單 12.AroundAdvice.java
public class AroundAdvice implements MethodInterceptor
{
public Object intercept(Object target, Method method
, Object[] args, MethodProxy proxy)
throws java.lang.Throwable
{
System.out.println("執行目標方法之前，模擬開始事務 ...");
// 執行目標方法，並保存目標方法執行後的返回值
Object rvt = proxy.invokeSuper(target, new String[]{"被改變的參數"});
System.out.println("執行目標方法之後，模擬結束事務 ...");
return rvt + " 新增的內容";
}
}
|
上面這個 AroundAdvice.java 的作用就像前面介紹的 Around Advice，它可以在調用目標方法之前、調用目標方法之後織入增強處理。
接下來程序提供一個 ChineseProxyFactory 類，這個 ChineseProxyFactory 類會通過 CGLIB 來爲 Chinese 生成代理類：
清單 13.ChineseProxyFactory.java
public class ChineseProxyFactory
{
public static Chinese getAuthInstance()
{
Enhancer en = new Enhancer();
// 設置要代理的目標類
en.setSuperclass(Chinese.class);
// 設置要代理的攔截器
en.setCallback(new AroundAdvice());
// 生成代理類的實例
return (Chinese)en.create();
}
}
|
上面粗體字代碼就是使用 CGLIB 的 Enhancer 生成代理對象的關鍵代碼，此時的 Enhancer 將以 Chinese 類作爲目標類，以 AroundAdvice 對象作爲“Advice”，程序將會生成一個 Chinese 的子類，這個子類就是 CGLIB 生成代理類，它可作爲 Chinese 對象使用，但它增強了 Chinese 類的方法。
測試 Chinese 代理類的主程序如下：
清單 14.Main.java
public class Main
{
public static void main(String[] args)
{
Chinese chin = ChineseProxyFactory.getAuthInstance();
System.out.println(chin.sayHello("孫悟空"));
chin.eat("西瓜");
System.out.println(chin.getClass());
}
}
|
運行上面主程序，看到如下輸出結果：
執行目標方法之前，模擬開始事務 ...
-- 正在執行 sayHello 方法 --
執行目標方法之後，模擬結束事務 ...
被改變的參數 Hello , CGLIB 新增的內容
執行目標方法之前，模擬開始事務 ...
我正在吃 : 被改變的參數
執行目標方法之後，模擬結束事務 ...
class lee.Chinese$$EnhancerByCGLIB$$4bd097d9
從上面輸出結果來看，CGLIB 生成的代理完全可以作爲 Chinese 對象來使用，而且 CGLIB 代理對象的 sayHello()、eat() 兩個方法已經增加了事務控制（只是模擬），這個 CGLIB 代理其實就是 Spring AOP 所生成的 AOP 代理。
通過程序最後的輸出，不難發現這個代理對象的實現類是 lee.Chinese$$EnhancerByCGLIB$$4bd097d9，這就是 CGLIB 所生成的代理類，這個代理類的格式與前面 Spring AOP 所生成的代理類的格式完全相同。
這就是 Spring AOP 的根本所在：Spring AOP 就是通過 CGLIB 來動態地生成代理對象，這個代理對象就是所謂的 AOP 代理，而 AOP 代理的方法則通過在目標對象的切入點動態地織入增強處理，從而完成了對目標方法的增強。
AOP 廣泛應用於處理一些具有橫切性質的系統級服務，AOP 的出現是對 OOP 的良好補充，它使得開發者能用更優雅的方式處理具有橫切性質的服務。不管是那種 AOP 實現，不論是 AspectJ、還是 Spring AOP，它們都需要動態地生成一個 AOP 代理類，區別只是生成 AOP 代理類的時機不同：AspectJ 採用編譯時生成 AOP 代理類，因此具有更好的性能，但需要使用特定的編譯器進行處理；而 Spring AOP 則採用運行時生成 AOP 代理類，因此無需使用特定編譯器進行處理。由於 Spring AOP 需要在每次運行時生成 AOP 代理，因此性能略差一些。
