語言機制
Mik Kersten
AOP 工具構建師、咨詢顧問, University of British Columbia
2005 年 2 月
AOP 技術的時代已經來臨，但是怎樣才能為項目選擇正確的工具呢？在新推出的 AOP@Work 系列的第一篇文章中，面向方面（aspect-oriented）的編程專家 Mik Kersten 將比較 4 個領先的 AOP 工具（AspectJ、AspectWerkz、JBoss AOP 和 Spring AOP），幫助大家判斷應該選擇哪一個工具。本文由兩個部分組成，在文中，作者將重點介紹這些工具的語言機制和不同技術的優劣。他分別用 4 種工具編寫同一個示例，讓讀者感覺到它們之間的高級區別。他還將討論每種工具的語法技術對 AOP 語義產生的效果。在文章結束時，作者將對工具的核心語言機制（例如切入點匹配和組合、通知的格式、連接點上下文）進行深入比較。注意，本文將解釋最近宣布的 AspectJ 和 AspectWerkz 項目合并的意義。
面向方面編程（AOP）在 Java? 平臺上變得日益流行。隨著 AOP 出版物和會議的增加，這項技術的工具與實現越來越多。雖然人們很清楚 AOP 是面向對象技術的補充，但是 Java 開發人員該如何評估當前的 AOP 工具，特別是每項新技術實現的優劣，這方面則相對不那么清楚。
本文有兩部分，而且本文還是 developerWorks 上一個新的 AOP 系列的第一篇文章。在本文中，將概述 AOP 工具當前的技術狀況，比較對于該技術而言最成熟的一些方法：AspectJ、AspectWerkz、JBoss AOP、和 Spring AOP，并對比與每種方法的采用有關的問題。文中還會解釋最近宣布的 AspectJ 和 AspectWerkz 項目合并的意義（請參閱參考資料）。
本文無意作為 AOP 的介紹或某個特定 AOP 實現的入門讀物。而是將對目前使用最普遍的 AOP 技術進行概述。對每個工具的語言機制和工具支持的內在優劣進行探討，將有助于為項目選擇最合適的技術。這里定義的指標還會讓讀者更加容易地評估即將推出的 AOP 工具和特性。關于 developerWorks 上介紹 AOP 的最新文章列表，請參閱參考資料。
請注意本文有兩個部分，為了方便讀者，兩部分同時發布。第 1 部分側重于這 4 個領先工具各自的 AOP 語言機制處理技術，其中包括工具的方面語法（aspect syntax）和切入點的表示、用來聲明方面的機制范圍等主題。第 2 部分繼續深入介紹領先的 AOP 實現如何與現有的開發環境、工具和庫進行集成。這一部分包括以下主題：方面設計器、IDE 插件、可伸縮性和 AOP 工具將來的發展方向，還包括對最近 AspectJ 和 AspectWerkz 項目合并的關注。
選擇成熟的工具
AOP 是一項新技術，所以，并不是現有的所有工具都已經成熟到適用于商業開發。判斷成熟度的一個主要因素是用戶的采用程度。在考慮把一項新編程技術應用到商用之前，這項技術必須從活躍的用戶社區的反饋中得到強化。表 1 顯示了 aosd.net 上列出的目前可以使用的 AOP 工具（請參閱參考資料）。每個工具的用戶列表貼子數量可以表明它的用戶基數（省略了貼子的實際數量，因為單獨一個月的統計可能給讀者造成誤解）。
表 1. 在 2004 年 11 月 AOP 工具用戶列表中的貼子數量
|
關于這個系列
AOP@Work 系列面對的是在面向方面編程上有些基礎，同時想擴展或加深這方面了解的開發人員。同 developerWorks 的大多數文章一樣，這個系列非常實用：讀完每篇介紹新技術的文章，都可以立即將其投入使用。
為這個系列選擇的每個作者都是面向方面編程領域的領導或專家。許多作者都是系列文章中介紹的項目和工具的參與者。每篇文章都力圖提供一個中立的評述，以確保這里表達的觀點的公正與正確。
請就文章的評論或問題分別與這些文章的作者聯系。要對這個系列整體進行評論，可以與這個系列的負責人 Nicholas Lesiecki 聯系。
關于本文
本文并不想突出某一個工具，而是要用一種批判的、沒有偏見的方式突出每個工具的優勢與不足。雖然作者是 AspectJ 項目的參與者之一，但是在編寫本文的時候，也咨詢了其他 AOP 工具項目的領導人，以確保公平地展示所討論的技術。 |
請注意 Spring 的 AOP 部分沒有形成一個獨立的下載或用戶社團，所以用戶基數相當比例的用戶可能沒有給 Spring AOP 發貼，而是投在別的主題上了。在 aosd.net 上還列出了 4 個額外的工具，但是它們要么缺乏用戶討論論壇，要么在 11 月沒有貼子。
AOP 工具雖然沒有列在表中前四位，但它在技術上可能非常成熟，可是缺乏較大的用戶基數就意味著它們還沒有經受過采納程度測試。雖然在本文編寫的時候，它們還不適合于商業開發，但是這些工具的日后發展還是值得關注的。通過上表的比較，還可以看出非 Java 平臺的 AOP 工具沒有 Java 平臺的工具成熟，但是應當注意 .NET 和 C++ 工具的用戶社區正在成長。
根據表 1，可以看出，從用戶采用度的角度來說，AspectJ、AspectWerkz、JBoss AOP 和 Spring AOP 是領先的工具。所有這些工具都是適合用于商業開發中的開源項目。按字母順序將它們排列如下，包括它們 V1.0 版本的發布日期：
- AspectJ —— 2001 年由 Xerox PARC 的 AOP 小組發行。目前主頁在 eclipse.org 上，由 IBM 支持。版本已經更新到 1.2.1。
- AspectWerkz —— 2002 年發布，由 BEA Systems 支持。版本更新到 2.0RC2。
- JBoss AOP —— 2004 年作為 JBoss 應用程序服務器框架的擴展發布。版本更新到 1.0。
- Spring AOP —— 2004 年作為 Spring 框架的擴展發布。版本更新到 1.1.3.
都是為了連接點
本文介紹的每個 AOP 工具都采用了連接點（join point）模型和機制，顯式地聲明程序的橫切結構。雖然各個工具實現這個框架的技術非常相似，但是理解底層機制對于了解每項技術的優劣是非常重要的。在這一節中，將回顧 AOP 的連接點模型以及利用連接點模型的語言模型。
支持機制
AOP 工具的設計目標是把橫切的問題（例如認證和事務管理）模塊化。在單獨使用面向對象技術實現的的時候，處理這些問題的代碼會分散在整個系統中，這種分散造成管理和發展橫切結構時出現不必要的困難。與對象提供了一種能夠清楚地捕獲繼承結構的語言機制類似，AOP 也為橫切問題的良好模塊化提供了同樣的好處。位于每個 AOP 工具核心的是連接點模型，它提供了一種機制，可以識別出在哪里發生了橫切。
連接點 就是主程序和方面相遇的地方。靜態連接點允許方面定義類上的新成員。動態連接點是方面執行與程序執行相遇的地方。例如，普通的 Java 程序執行方法調用、字段設置這樣的連接點。再比如說，請考慮一下這樣一個問題：對改變 Account 狀態的活動進行監視，就像在 Ramnivas Laddad 的 AspectJ in Action 一書中討論的那樣（請參閱參考資料）。 圖 1 中的順序圖突出了在 Account 操作上形成的一些動態連接點。
圖 1. 突出了選中的動態連接點的 UML 序列圖
下面的編號與圖中的編號對應：
- 方法執行 連接點，與方法返回之前的生命周期對應。
- 控制流程 捕捉在控制流程序列中出現的各個連接點；在這個例子中，在
debit() 方法調用下方的序列描述了在 debit() 調用中發生的全部連接點。
- 字段訪問 連接點對應著字段的讀和寫；在這個例子中，在
Account 類上對 name 字段進行了賦值。
|
AspectJ 和 AspectWerkz 項目合并
AOP 技術正在迅速地向前發展，在本文的第 2 部分突出了領先的 AOP 工具的預計的發布計劃。有一個那些思想超前的讀者會特別感興趣的主題，這就是最近 AspectJ 與 AspectWerkz 項目的合并，這一合并會給 AOP 的發展前景帶來重大的變化。一些開發人員在這些項目上進行合作，生產 AspectJ 5，這是一種單一工具，融合了這里介紹的 AspectJ 和 AspectWerkz 的語法。
重要的是要注意 AspectWerkz 并沒有正在消失。它將成為編寫 AspectJ 程序的另一種方法，并更名為 @AspectJ 風格。在這里可以看到，語法是 AOP 實現之間的主要區別因素，而核心的 AOP 機制通常非常相似。 AspectWerkz 和 AspectJ 的相似性使得這兩種技術可以聯合。合并可以在提供方面語法的時候提供更多的靈活性，同時保留著關鍵的好處（例如靜態類型化和成熟的工具支持）。有關合并的細節以及相關文檔，可以從參考資料中得到。雖然本文重點放在立刻就可以開始使用的工具上，但是這里概述的指標和優劣也適用于未來的發行版（例如 AspectJ 5）。 |
切入點、通知和類型間聲明
AOP 工具提供了識別連接點集合的機制，叫作切入點（pointcut）。通知（advice） 機制指定在程序執行過程中遇到匹配的切入點時應當采取什么行動。另外，類型間聲明（inter-type declaration）（開放類或混合類提供了在現有類型上聲明額外成員的方法。切入點、通知和類型間聲明組合在一起，使 AOP 語言可以清楚地表達橫切問題。方面 聲明可以在標準的 Java 字段和方法之外包含這三類成員。方面代表一套模塊化良好的橫切結構。如下所示，不同的 AOP 技術實現這些方法的技術各不相同。但是，每種技術的核心，都是連接點的訪問、編輯、命名和抽象機制。
切入點可以通過顯式枚舉方式描述連接點集合。應當用一個示例指定圖 1 所示的 Account 的利息的三個方法調用。雖然枚舉可能很有用，但是用結構化屬性的方式表示連接點通常更方便。這類基于屬性的切入點可以表示一套與“每個針對 Account 子類型的調用”匹配的連接點，卻不必強迫程序員枚舉這些子類型。這樣做可以保證向系統添加由 Account 擴展的新類時，新類會自動與切入點匹配。
切入點支持復合（composition），這就允許把簡單的切入點組合成更復雜的切入點。例如，可以把所有 Account 調用的切入點限制在那些針對特定類或控制流程進行的調用中。切入點的命名（naming）機制提高了可讀性和復合性。對抽象（abstraction）與具體化（concretization）的支持，可以更加容易地創建通用庫，對于要應用庫的特定應用程序的切入點來說，這些庫可以獨立定義。最后，對切入點中公開連接點狀態 的支持允許對諸如正在執行對象和方法參數之類的訪問事項進行商量。
方面比較
如前所述，所有 AOP 工具的底層機制都是連接點和切入點、通知和類型間聲明的概念。在這些工具中，可以注意到的主要區別就是方面聲明編寫及應用到系統上的方式。這些工具可用以下方法中的一種進行方面聲明：使用類似 Java 的代碼、注釋或 XML。對于某些開發人員來說，熟悉用 Java 語言編程方面的知識，要比熟悉語言擴展技術的優劣更重要，這些內容會在后面的小節中討論。對于其他人來說，了解注釋和 XML 技術在集成上的優勢，要比痛苦地把切入點當作字符串來操作更重要。
在這一節中，將使用一個常見的示例指出每個工具在方面聲明技術上的差異。請考慮圖 1 所示的 Account 類的授權策略這樣一個示例。在面向對象的實現中，最常見到的，就是對認證的調用分散在 Account 類的眾多方法以及需要認證的其他類中。在 AOP 實現中，可以明確地用一個方面捕獲這個行為，而不必修改操縱帳戶的代碼。不管使用什么工具聲明，這個方面都需要具備以下特征：
- 一個切入點，捕捉
banking.Account 類上所有公共方法的執行。
- 一種引用正在認證的
Account 的方式。
- 通知，在切入點指定的連接點上調用
Account 的認證。
現在，請看這幾個領先的 AOP 工具各自是如何處理這個方面的。
AspectJ
Aspect 中的方面聲明類似于 Java 語言中的類聲明，如圖 2 所示。由于 AspectJ 是 Java 語言語法和語義的擴展，所以它提供了自己的一套處理方面的關鍵字。除了包含字段和方法之外，AspectJ 的方面聲明還包含切入點和通知成員。示例中的切入點使用了修飾符（modifier）和通配符（wildcard）模式來表達“所有公共方法”。對帳戶的訪問，由 pointcut 參數提供。通知使用這個參數，而切入點則用 this(account) 把它綁定。這樣做的效果，就是捕獲了正在執行的方法所隸屬 Account 對象。否則，通知的主體與方法的主體相似。通知可以包含認證代碼，或者就像在這個示例中一樣，可以調用其他方法。
圖 2. AspectJ 的方面
構建 AspectJ 程序與構建 Java 程序類似，其中包括調用 AspectJ 的遞增編譯器，構建所有的項目源文件，包括普通的 Java 源文件。運行 AspectJ 程序也與運行 Java 程序一樣，請注意要把 aspectjrt.jar 庫添加到類路徑中。要對在系統中應用哪個方面進行配置，必須把它們加入包含列表或從中刪除，包含列表會傳遞給編譯器，可以通過 IDE 支持傳遞包含列表，如果正在 Ant 環境或命令行進行工作，也可以通過“.lst” 包含文件傳遞。注意，在第 2 部分中，將討論構建 AOP 程序的細節以及方面設計的概念。
AspectWerkz
AspectWerkz 和 AspectJ 之間的重要區別就是： Authentication 現在是一個普通的 Java 類，而不是一個方面。AspectWerkz、JBoss AOP 和 Spring AOP 都在沒有改變 Java 語言語法的情況下加入了方面語義。AspectWerkz 提供了兩種進行 AOP 聲明的途徑。最常用的是注釋，注釋可以采用圖 3 中的 Java V5.0 風格，也可以為了與 J2SE V1.4 兼容采用 Javadoc 風格。AspectWerkz 還支持另外一種基于 XML 的方面聲明風格。XML 風格與下面介紹的 JBoss AOP 的風格類似，把方面聲明放在單獨的 XML 文件中。
請注意通知就是普通的方法聲明。按照約定，它被當作不同類型的方法聲明，因為不應當顯式地調用它，而是應該在滿足特定切入點時自動運行它。AspectWerkz 的切入點聲明是附加到切入點“方法”的字符串值，也可以在 XML 文件中獨立存在。所以，沒有切入點的 import 機制，所有的類型引用必須完全規范。對正在運行的 Account 對象的訪問技術與 AspectJ 相同。請注意，規劃的 @AspectJ 語法看起來與 AspectWerkz 注釋的語法非常相似。
圖 3. AspectWerkz 的方面
構建 AspectWerkz 程序會涉及一個標準的 Java 構建，然后會涉及到后處理。要運行 AspectWerkz 程序，必須把 AspectWerkz 庫放在類路徑中。在使用不可插入的方面的情況下，由 aop.xml 文件配置系統中一些方面的包含情況。
JBoss AOP
JBoss AOP 基于 XML 的方面來聲明風格，如圖 4 所示。JBoss 也支持與圖 3 所示相似的注釋風格。在 XML 風格中，方面、切入點和通知聲明都以 XML 形式表示的。通知的實現，用的是普通的 Java 方法，由 JBoss AOP 框架調用。切入點和切入點到通知的綁定都在方面中用 XML 注釋聲明。JBoss 沒有顯式地綁定 Account 參數，而是提供了對當前正在執行的對象的反射訪問，因此需要把類型轉換到對應的類型。注意，即將發布的 JBoss 會提供一些靜態類型的切入點參數來解決這一問題。
圖 4. JBoss AOP 的方面
用 JBoss 構建方面只包括普通的 Java 構建。JBoss AOP 的運行時截取框架（interception framework）負責管理切入點匹配和通知調用。需要對啟動和類路徑做一些配置，但是 JBoss AOP 的 IDE 插件替用戶做了這些工作。方面在 jboss-aop.xml 文件中配置。
Spring AOP
查看圖 5 中的 Spring AOP 示例時，可以注意到其中的 XML 比前面介紹的技術多。與 JBoss AOP 類似，Spring 的通知實現是帶有特殊參數的 Java 方法，由 Spring 框架調用。XML 描述 accountBean，Spring 框架通過它訪問 Account 對象，包括通知使用的攔截器 advisor 及其匹配模式，還有應用到模式的向前（before） 通知。
圖 5. Spring AOP 的方面
Spring AOP 的技術雖然提供了更加精細的配置，但在將它用于 XML 時，它與 JBoss AOP 非常類似。構建、運行和配置 Spring AOP 方面的過程與 JBoss AOP 相同，但 Spring AOP 依賴的是 Spring 框架方便的、最小化的運行時配置，所以不需要獨立的啟動器。請注意，使用這個技術，只能通知從 Spring 框架檢索出的對象。
語法差異
正如上面的圖所展示的，AOP 工具之間的關鍵差異就是處理方面聲明的方式。AspectJ 是 Java 語言的擴展，用它可以完全在代碼中對方面進行聲明。AspectWerkz 和 JBoss AOP 支持用方面元數據對 Java 代碼進行注釋，或者在獨立的 XML 文件中對方面進行聲明。在 Spring AOP 中，則完全用 XML 對方面進行聲明。所以，在三種不同的技術中，對方面進行編程的感覺可能非常不同。用 AspectJ 的代碼風格，方面和切入點聲明感覺起來就像 Java 代碼。而用 JBoss AOP 或 AspectWerkz 的注釋風格，感覺起來就像在現有 Java 元素上做的附加標簽。而用 Spring AOP 風格，以及 AspectWerkz 和 JBoss AOP 的 XML 風格 時，感覺就像使用獨立的聲明性 XML 語言。
每種技術都有它的優勢，具體要由使用者決定哪個更適合需求。所以在這一節，將簡要地討論一些能夠有助于進行決策的要點。
自己的風格是什么？
不管選擇哪個 AOP 工具，使用通知主體時只涉及到使用 Java 代碼。如果需要修改切入點，那么區別是非常透明的。在使用 XML 風格時（就像在 Spring AOP 中），修改切入點包括：從通知找到 XML 文件中對應的切入點聲明。從正面來說，這項技術把切入點和方面配置的工作全都局限于本地，但是如果要編輯許多通知和切入點，而且要在 Java 和 XML 之間重復地翻來覆去，那么這項工作就會變得很繁瑣。
如果使用 AspectWerkz 或 JBoss AOP 提供的注釋風格，那么就可以把切入點的表達值從 XML 轉移到 Java 成員的注釋。這樣可以更容易地并發處理通知體和切入點。如果選擇了 AspectJ 的代碼風格，那么就會發現處理切入點感覺就像處理代碼，而不像是處理非結構化的字符串值。從 Java 代碼能得到的一切（例如“import”語句），都可以用于切入點。對比之下，如果用 AspectWerkz、JBoss AOP 和 Spring AOP 的 XML 和注釋風格，總是需要在規范切入點中的類型引用。
簡潔還是繁瑣？
方面聲明的風格對每個工具中使用的方面有很大的影響。例如，支持在 XML 中聲明方面的工具，也支持在同一 XML 文件中對方面應用到系統的方式進行配置。在前面的小節中，只展示了切入點和方面聲明，但是類型間聲明同樣受到風格選擇的影響。在 AspectJ 中，類型間方法聲明看起來就像正常的方法聲明，引用的技術也一樣。而在其他技術中，則要指定一個類，擴展額外的混合類并繼承那些額外的成員，通過注釋或 XML 添加新方法。注意，目前 AspectJ 是惟一提供使用切入點的靜態強制機制的工具。表 2 比較了這些工具對 AOP 語法的關鍵元素的處理技術。
表 2. 比較領先的 AOP 工具中的語法
顯然，從圖 2-5 的方面聲明來看，代碼風格是處理 AOP 聲明最簡潔的技術。它不需要對通知命名，也不需要顯式地調用通知。代碼風格不需要顯式地把通知綁定到切入點（就像 XML 風格那樣），也不需要把通知綁定到 return 語句（這是 AspectWerkz 的切入點“方法”所需要的）。對于可以在 圖 3 和 圖 4 的 XML 中看到的復雜設計，AspectJ 對 Java 語言進行的語法擴展允許直接表示這些設計。用 AspectJ 編寫方面，感覺起來更像是編寫 Java 代碼，避免了冗余的鍵入，因此出錯也就更少。從不好的一面來說，Java 的語法擴展代價巨大，而注釋和 XML 風格有它們獨特的優勢。最明顯的就是 XML 風格可以控制切入點和通知的綁定。這對于擴展和配置方面非常有益，在下面一節中將討論這點以及不同風格帶來的其他優缺點。
代碼風格與注釋和 XML 的比較
那么，應當采用代碼風格，還是用注釋或 XML 聲明方面呢？以下是基于 AspectJ 的 Java 代碼的一些技術的優缺點總結：
- 簡明語法充分利用對 Java 代碼的熟悉，減少鍵入錯誤，使錯誤更少。
- 切入點是一級實體，因此更容易對它們進行處理。
- 對于許多開發人員，用 XML 進行聲明性編程要比用 Java 語言擴展更熟悉。
- 通知到切入點的綁定不能由開發人員控制。
如果這個小結仍然無法縮小決策范圍，那么不要擔心。除了用每種風格編寫這些方面的感覺之外，還有更多需要考慮的東西。當在下一節中查看語義的時候，語法決策還會出現，而且也會影響在第 2 部分中討論的工具支持。
語義的相似性
雖然工具的方面聲明風格之間存在主要的語法差異，但是核心的 AOP 語義是類似的。每個工具都有完全相同的連接點模型的概念，都把連接點作為 Java 程序中的關鍵點，把切入點作為匹配連接點的機制，把通知作為指定連接點匹配時執行操作的機制。
表 3 和 表 4 總結了每種技術的語義。您可以注意到，命令規范上有許多微小的差異和變化，但是各種技術最終聚合在相同的核心概念上。這種聚合有很大的好處，因為這意味著學習曲線很容易從一項 AOP 技術轉移到另外一項 AOP 技術。剩下來要考慮的就是每種技術的差異所帶來的優劣了。
回到連接點
一個 AOP 工具連接點模型的表達方式決定了可用的連接點粒度，以及連接點如何匹配。每個 AOP 工具都提供了大量用于連接點匹配的原生切入點。有些原生切入點只與特定類型的連接點匹配（例如，方法執行）。其他切入點能夠根據連接點的公共屬性（例如，在某個控制流程中的所有連接點）匹配任何類型的連接點。連接點的類型以及它們特定的切入點，可以分成以下幾組：
- 調用（Invocation）—— 調用或執行方法和其他代碼元素時的點。
- 初始化（Initialization）—— 初始化類和對象時的點。
- 訪問（Access）—— 讀寫某些字段時的點。
- 異常處理（Exception handling）—— 拋出和處理異常與錯誤時的點。
另外，也支持以下沒有類型的切入點分類：
- 控制流程（Control flow）—— 在某個流程控制流程中的連接點。
- 包含（Containment）—— 與包含在某個類或方法中的代碼位置對應的連接點。
- 條件（Conditional）—— 特定預測為真的連接點。
如表 3 所示，每個工具實現連接點模型的方式，以及它們用來匹配連接點的原生切入點，都略有差異。注意，在某些情況下（在括號中表示），連接點不用切入點標識。
表 3. 連接點和用來匹配連接點的原生切入點
要富于表現力還是要簡單？
在這里主要的優劣在于富于表現力和簡單性的比較。更加完整和精細的切入點集合允許通過方面訪問程序執行中更多有趣的點。例如，與持久性有關的方面可能需要訪問對象的初始化連接點。但是這類完整性也會帶來額外的復雜性和更陡峭的學習曲線。許多 Java 程序員并不區分調用和執行，而且沒有幾個人需要理解初始化的微妙之處。而且許多常用的方面被當作是輔助性的，所以是否有表現力與應用程序的功能并沒有緊密耦合。在常用的輔助性方面，例如監視和日志，通常只利用了粗粒度的切入點（例如方法執行）。從反面來看，更廣泛的切入點集合確實具備量入為出的屬性，因為切入點可以邊用邊學。如果不想用切入點制作程序，那么會造成面向對象代碼的強制重構，例如：以 init() 方法的形式公開類的初始化。
AspectJ 和 AspectWerkz 的連接點模型差不多完全融合，而且已經成為最近的合并的關鍵促進者之一。JBoss AOP 模型幾乎同樣有表現力，只是為了簡單性而遺漏了一些不太常用的連接點。一個明顯的差異是：在 JBoss Aop 中，不能把控制流程表示成“在這個切入點的執行之下的所有連接點”。相反，程序員需要手動列出調用堆棧中的每個調用。
Spring AOP 采用了不同的技術，目的是限制它的連接點模型的表現力。這使它特別容易采用，而且對于一些粗粒度的橫切很有用。即將發行的版本將與 AspectJ 集成，提供與精細橫切機制的互操作性。
連接點模型的表現力與簡單性的比較
一些項目可以從更有表現力的連接點模型（例如 AspectWerkz、AspectJ 和 JBoss AOP 提供的）獲益，所以最好還是采用 Spring AOP 粗粒度的方便性？以下是更有表現力的模型固有優缺點的一個總結，多考慮一下這些方面會對您有所幫助：
- 了解更多知識 。
- 對于粗粒度的橫切和輔助性方面，只需要很少的切入點。
- 沒有精細的切入點，許多方面就不能表達。
- 使用新切入點的學習曲線是隨用隨學。
語言機制
我將用每種技術語言機制的詳細對比結束 AOP 工具比較的第一部分的討論。表 4 是 4 個工具的 AOP 語言的概括。下面討論了最明顯的區別。
表 4. 領先的 AOP 工具的語義概括
切入點匹配和復合：AspectJ、AspectWerkz 和 JBoss AOP 提供了類似的類型模式支持。它們三個都允許簽名方面的匹配，對于 Java 5 應用程序來說，這些匹配包括注釋和泛型。AspectJ 和 AspectWerkz 提供了一種簡潔的引用多個類型的技術（例如 Account+ 表示帳戶的所有子類型）。所有的工具都支持通配符匹配。Spring AOP 還提供了對正則表達式的支持。雖然這看起來可能是一個強大的優勢，但還是要指出其他技術已經選擇了放棄正則表達式，好讓切入點讀起來不是太難，同時不會存在潛在的損害。切入點復合操作符基本上都是相同的。Spring AOP 不提供“非”操作，這個操作通常與沒有在 Spring AOP 連接點模型的容器（containment）連接點結合使用。
通知形式：AspectJ 支持比其他技術更多的通知形式，而 JBoss AOP 只支持一種通知形式。每種通知形式都可以表達成 around 通知，所以 JBoss 的技術是無限的，而且它確實提供了額外的簡單性。不好的一面是它損失了簡潔性，這一點可以從需要進行額外的調用才能繼續執行原來的方法調用（如 圖 4 所示）看得出來，而如果用 before 進行通知，這一點就是不必要的。還請注意，強迫通知去遵守普通的 Java 規則（就像注釋和 XML 風格做的那樣），在一些情況下容易出問題，因為這些規則是為方法設計的。AspectJ 擁有把被通知方法的異常“軟化”的能力，這很有用，但是不符合方法異常檢測的標準語義。
連接點上下文：在 AspectJ 和 AspectWerkz 中，通過指定和綁定切入點參數訪問動態連接點的狀態，類似于在 Java 語言中聲明方法參數的技術（請參閱圖 2 和 圖 3）。這為連接點上下文提供了靜態類型化的好處。JBoss AOP 和 Spring AOP 反射性地訪問連接點的狀態，這消除了在切入點表達式中參數綁定的復雜性，代價是參數靜態類型化。Java 程序員習慣了方法參數靜態類型化帶來的好處，同時還可以從切入點參數的靜態類型化得到同樣的好處。所以，在 JBoss AOP 最近的發行版本中，有提供靜態類型化的“args” 的計劃。
實例化：在所有的工具中，方面的實例化是由 per 子句控制的。正如所料，Spring AOP 的實例化模型更簡單。對于額外的實例化機制的支持，則意味著可以把方面編寫成只能應用于特定的動態上下文環境中，不用編寫代碼保存這個上下文并測試其他方面是否該應用這個方面。主要的區別因素是 AspectJ 支持在每個控制流程進行方面初始化，AspectWerkz 支持每個線程的初始化，而 JBoss 則支持每個連接點的初始化。哪種最有用則取決于具體的需求。
擴展性：方面的擴展性支持庫方面的部署，這樣可以在日后為特定程序而將這些庫方面具體化。例如，一個方面庫可以提供應用程序監視需要的全部邏輯和基礎設施。但是，要采用某個特定項目的庫，那么庫使用的切入點必須擴展成應用程序特定的連接點。AspectJ 用抽象方面支持擴展性，抽象方面包含抽象的切入點和具體的通知。擴展抽象方面的子方面必須具體化切入點。AspectWerkz 和 JBoss AOP 使用了完全不同的技術，沒有使用抽象切入點機制。擴展是通過生成方面的子類、并在 XML 中或通過注釋定義新的通知綁定而實現的。切入點到通知的顯式綁定為 AspectWerkz 和 JBoss AOP 提供了顯著優勢，從而可以很容易地把方面擴展到新系統，無需要生成子類。方面庫的使用數據正在日益增多，這些將決定與其他技術使用的 Java 風格的繼承和切入點綁定相比，AspectJ 特殊的 AOP 繼承形式是更好還是更差。
每項技術在處理 AOP 的語言機制時，都提供了自己獨特的優缺點。用一個簡單的列表來總結這些優缺點是不可能的，因為對于不同的項目，每項技術的好處是各不相同的。但是，以上信息為選擇工具或者遇到關鍵問題時尋找替代品提供了指南。
結束語
為項目選擇一個 AOP 工具所面臨的難題在于比較每種工具的優劣，同時不要讓自己迷失其中。AOP工具比較的第一部分強調了 4 種領先的 AOP 技術的核心機制，并對比了它們的相似與不同之處。
如果本文是在十年之前報道一項新的模塊化技術，那么我們可能就此打住，開始用自己選擇的風格來編寫方面 —— 可能是在命令行用 Emacs 或其他文本編輯器構建。但是今天，如果沒有深入研究一項新技術如何與現有的開發環境和其他工具集成，人們是不會輕易地考慮采用它的。
所以，本文的第二部分把重點放在集成因素對 AOP工具選擇的影響。在其他因素之中，將討論每個工具如何處理方面的編譯與設計，以及如何依據 IDE 集成與工具支持將它們都組合在一起。我還會比較這些工具的基本特性，看看它們背后到底是什么，包括進一步探討 AspectJ 與 AspectWerkz 項目合并之后我們可以期盼從中得到什么。
參考資料
關于作者
Mik Kersten 是一流的面向方面的編程專家，也是 AspectJ 和 AJDT eclipse.org 項目的參與者。作為 Xerox PARC 的研究科學家，他為 AspectJ 構建了 IDE 支持。他正在不列顛哥倫比亞大學攻讀博士學位，他的主要工作是使 IDE 更加面向方面。他也向構建開發工具的公司提供咨詢，幫助公司利用、支持面向方面的編程技術。 |
|