|
級(jí)別： 初級(jí)
王海龍 (buaawhl@sina.com),
2003 年 7 月 01 日
網(wǎng)上出現(xiàn)了很多講解AspectJ的資料，但大多是從講解AspectJ語法開始,本文從另一個(gè)角度講解AspectJ，作者著重介紹了AspectJ的設(shè)計(jì)思路和運(yùn)行原理。
1. 序
Aspect Oriented Programming (AOP)是近來一個(gè)比較熱門的話題。
AspectJ是AOP的Java語言的實(shí)現(xiàn)，獲得了Java程序員的廣泛關(guān)注。
關(guān)于AspectJ和AOP的具體資料，請(qǐng)從下列鏈接中查找：
http://www.eclipse.org/aspectj/
http://www.parc.com/research/csl/projects/aspectj/
http://aosd.net/
網(wǎng)上出現(xiàn)了很多講解AspectJ的資料，但大多是從講解AspectJ語法開始，然后講解如何應(yīng)用AspectJ，如何分離軟件開發(fā)過程的不同方面（Aspect）--Log，Session，Authentication and Authorization，Transaction，等等。
初次接觸AspectJ的讀者看到這些資料（或者語法手冊(cè)），會(huì)感到AspectJ有些神秘。他們想知道，AspectJ是如何做到這些的？AspectJ是怎樣工作的？AspectJ需要特殊的運(yùn)行環(huán)境嗎？
本文從另一個(gè)角度講解AspectJ，本文從講解AspectJ的設(shè)計(jì)思路、運(yùn)行原理入手，回答上述問題。
本文講解的主要內(nèi)容，按照概念的重要程度，排列如下：
- AspectJ是一個(gè)代碼生成工具（Code Generator）。
- AspectJ語法就是用來定義代碼生成規(guī)則的語法。您如果使用過Java Compiler Compiler (JavaCC)，您會(huì)發(fā)現(xiàn)，兩者的代碼生成規(guī)則的理念驚人相似。
- AspectJ有自己的語法編譯工具，編譯的結(jié)果是Java Class文件，運(yùn)行的時(shí)候，classpath需要包含AspectJ的一個(gè)jar文件（Runtime lib）。
- AspectJ和xDoclet的比較。AspectJ和EJB Descriptor的比較。
本文的原則是，只細(xì)講其他資料沒有講到的東西，其他資料講過的東西，不講或略講。以節(jié)省網(wǎng)絡(luò)資源，更為了節(jié)省大家寶貴的時(shí)間。J
2．Aspect Oriented Programming (AOP)
本節(jié)簡(jiǎn)單介紹AOP的概念，解釋我們?yōu)槭裁葱枰狝OP。
AOP是Object Oriented Programming（OOP）的補(bǔ)充。
OOP能夠很好地解決對(duì)象的數(shù)據(jù)和封裝的問題，卻不能很好的解決Aspect（"方面"）分離的問題。下面舉例具體說明。
比如，我們有一個(gè)Bank（銀行）類。Bank有兩個(gè)方法，deposit（存錢）和withdraw（取錢）。
類和方法的定義如下：
Code 2.1 Bank.java
class Bank{
public float deposit(AccountInfo account, float money){
// 增加account賬戶的錢數(shù)，返回賬戶里當(dāng)前的錢數(shù)
}
public float withdraw(AccountInfo account, float money){
// 減少account賬戶的錢數(shù)，返回取出的錢數(shù)
}
};
|
這兩個(gè)方法涉及到用戶的賬戶資金等重要信息，必須要非常小心，所以編寫完上面的商業(yè)邏輯之后，項(xiàng)目負(fù)責(zé)人又提出了新的要求--給Bank類的每個(gè)重要方法加上安全認(rèn)證特性。
于是，我們不得不分別在上面的兩個(gè)方法中加入安全認(rèn)證的代碼。
類和方法的定義如下：（新增加的代碼用不同的背景標(biāo)出）
Code 2.2 Bank.java
class Bank{
public float deposit(AccountInfo account, float money){
// 驗(yàn)證account是否為合法用戶
// 增加account賬戶的錢數(shù)，返回賬戶里當(dāng)前的錢數(shù)
}
public float withdraw(AccountInfo account, float money){
// 驗(yàn)證account是否為合法用戶
// 減少account賬戶的錢數(shù)，返回取出的錢數(shù)
}
};
|
這兩個(gè)方法都需要操作數(shù)據(jù)庫，為了保持?jǐn)?shù)據(jù)完整性，項(xiàng)目負(fù)責(zé)人又提出了新的要求--給Bank類的每個(gè)操作數(shù)據(jù)庫的方法加上事務(wù)控制。
于是，我們不得不分別在上面的兩個(gè)方法中加入安全認(rèn)證的代碼。
類和方法的定義如下：（新增加的代碼用不同的背景標(biāo)出）
Code 2.3 Bank.java
class Bank{
public float deposit(AccountInfo account, float money){
// 驗(yàn)證account是否為合法用戶
// Begin Transaction
// 增加account賬戶的錢數(shù)，返回賬戶里當(dāng)前的錢數(shù)
// End Transaction
}
public float withdraw(AccountInfo account, float money){
// 驗(yàn)證account是否為合法用戶
// Begin Transaction
// 減少account賬戶的錢數(shù)，返回取出的錢數(shù)
// End Transaction
}
};
|
我們看到，這些與商業(yè)邏輯無關(guān)的重復(fù)代碼遍布在整個(gè)程序中。實(shí)際的工程項(xiàng)目中涉及到的類和函數(shù)，遠(yuǎn)遠(yuǎn)不止兩個(gè)。如何解決這種問題？
我們首先來看看OOP能否解決這個(gè)問題。
我們利用Design Pattern的Template Pattern，可以抽出一個(gè)框架，改變上面的例子的整個(gè)設(shè)計(jì)結(jié)構(gòu)。
類和方法的定義如下：
Code 2.4 Base.java
abstract class Base{
public float importantMethod(AccountInfo account, float money){
// 驗(yàn)證account是否為合法用戶
// Begin Transaction
float result = yourBusiness(account, money)
// End Transaction
return result;
}
protected abstract float yourBusiness(AccountInfo account, float money);
};
Code 2.5 BankDeposit.java
class BankDeposit extends Base{
protected float yourBusiness(AccountInfo account, float money){
// 增加account賬戶的錢數(shù)，返回賬戶里當(dāng)前的錢數(shù)
}
};
Code 2.6 BankWithdraw.java
class BankWithdraw extends Base{
protected float yourBusiness(AccountInfo account, float money){
// 減少account賬戶的錢數(shù)，返回取出的錢數(shù)
}
};
|
這里我們用一種很勉強(qiáng)的方法實(shí)現(xiàn)了認(rèn)證和事務(wù)代碼的重用。而且，有心的讀者可能會(huì)注意到，這種方法的前提是，強(qiáng)制所有的方法都遵守同樣的signature。
如果有一個(gè)轉(zhuǎn)賬方法transfer(AccountInfo giver, AccountInfo receiver, float money)，由于transfer方法的signature不同于yourBusiness的signature，這個(gè)方法無法使用上面的框架。
這個(gè)例子中提到的認(rèn)證，事務(wù)等方面，就是AOP所關(guān)心的Aspect。
AOP就是為了解決這種問題而出現(xiàn)的。AOP的目的就是--Separation of Aspects (or Separation of Concerns).
下面的章節(jié)，解釋EJB Descriptor，AspectJ，xDoclet等工具如何解決Separation of Aspects的問題。
3．EJB Descriptor
如果我們使用EJB實(shí)現(xiàn)上面的例子，Bank類可以作為一個(gè)Stateless Session Bean實(shí)現(xiàn)。
在Bank的代碼中只用考慮商業(yè)邏輯，不用考慮認(rèn)證和事務(wù)等方面。
認(rèn)證和事務(wù)等方面在EJB Descriptor中定義，由EJB Container提供這些方面的實(shí)現(xiàn)。
我們來看一下，如何使用EJB Descriptor描述上面的例子。
EJB Descriptor包括一個(gè)ejb-jar.xml文件。ejb-jar.xml文件包含兩大部分，enterprise-beans和assembly-descriptor部分。enterprise-beans部分包含EJB的定義--JNDI Name，EJB Home, Interface, Bean Class Path等；assembly-descriptor部分包括配置信息的定義--安全角色，事務(wù)控制等等。
下面給出上面例子對(duì)應(yīng)的模擬EJB Descriptor。
<ejb-jar>
<enterprise-beans>
<session>
<ejb-name>Bank</ejb-name>
…
<ejb-class>example.Bank</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
<security-role-ref>
<role-name>bank-account</role-name>
</security-role-ref>
</session>
</enterprise-beans>
<assembly-descriptor>
<security-role>
<role-name>bank-account</role-name>
</security-role>
<method-permission>
<role-name>employee</role-name>
<method>
<ejb-name>Bank</ejb-name>
<method-name>deposit</method-name>
</method>
<method>
<ejb-name>Bank</ejb-name>
<method-name>withdraw</method-name>
</method>
</method-permission>
<container-transaction>
<method>
<ejb-name>Bank</ejb-name>
<method-name>deposit</method-name>
</method>
<method>
<ejb-name>Bank</ejb-name>
<method-name>withdraw</method-name>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
</assembly-descriptor>
</ejb-jar>
|
本文后面會(huì)講到如何用AspectJ實(shí)現(xiàn)上例中的Separation of Aspects。
讀者可以比較一下AspectJ語法和EJB Descriptor定義之間的對(duì)應(yīng)關(guān)系。
兩者都提供了類名、方法名的匹配規(guī)則，能夠把類的方法映射到認(rèn)證，事務(wù)等Aspect（方面）。
4．AspectJ
這一節(jié)我們來看看AspectJ如何實(shí)現(xiàn)上例中的Separation of Aspects。
使用AspectJ，我們不用對(duì)原有的代碼做任何修改，就可以為代碼提供不同的Aspect（方面）--比如，認(rèn)證，事務(wù)等。
我們只需要提供兩個(gè)不同的Aspect--認(rèn)證Aspect和事務(wù)Aspect。
Code 4.1 AuthAspect.java
aspect AuthAspect{
pointcut bankMethods() : execution (* Bank.deposit(…)) || execution (* Bank. withdraw (…));
Object around(): bankMethods(){
// 驗(yàn)證account是否為合法用戶
return proceed();
}
};
Code 4.2 TransactionAspect.java
aspect TransactionAspect{
pointcut bankMethods() : execution(* Bank.deposit(…)) || execution (* Bank. withdraw (…));
Object around(): bankMethods(){
// Begin Transaction
Object result = proceed();
// End Transaction
return result;
}
};
|
如果您暫時(shí)不能理解這段代碼，沒有關(guān)系，后面會(huì)講到，這些aspect的定義，不過是定義了一些代碼生成規(guī)則。
我們用AspectJ編譯器編譯Bank文件和含有aspect的這個(gè)文件，出來的結(jié)果就是帶有安全認(rèn)證和事務(wù)處理的Bank類。編譯出來的這個(gè)Bank類調(diào)用了AspectJ Runtime Lib，所以，如果你要運(yùn)行這個(gè)Bank類，你需要把AspectJ Runtime Lib設(shè)置在你的classpath里面。
我們來看看，AspectJ編譯器為我們做了什么事情。
- 首先，AspectJ從文件列表里取出所有的文件名，然后讀取這些文件，進(jìn)行分析。
- AspectJ發(fā)現(xiàn)一些文件含有aspect的定義，在這個(gè)例子里，就是AuthAspect和TransactionAspect的定義；這些aspect就是代碼生成規(guī)則。
- AspectJ根據(jù)這些aspect代碼生成規(guī)則，修改添加你的源代碼。在這個(gè)例子里，就是修改添加Bank文件。
- AspectJ讀取AuthAspect的定義，發(fā)現(xiàn)了一個(gè)pointcut--bankMethods()；這個(gè)pointcut的定義是execution(* Bank.deposit(…)) || execution(* Bank. withdraw (…))，表示所有對(duì)Bank類的deposit和withdraw方法的執(zhí)行點(diǎn)。
- AspectJ繼續(xù)讀取AuthAspect的定義，發(fā)現(xiàn)了一個(gè)around()，這在AspectJ中叫做Advice，我不明白為什么叫這個(gè)名字，不過沒關(guān)系，我們只要知道它是干什么的就行了。Advice允許你在某個(gè)類的方法的調(diào)用之前或調(diào)用之后，加入另外的代碼。Code 4.1所示代碼中的around()的" // 驗(yàn)證account是否為合法用戶"部分，就是要加入的代碼。這段代碼要加在哪里呢？around()后面跟了一個(gè)pointcut--bankMethods()。根據(jù)這個(gè)pointcut，AspectJ會(huì)把這段代碼加入到Bank.deposit和Bank.withdraw兩個(gè)方法的執(zhí)行之前。達(dá)到的效果就如同Code 2.2所示。
- AspectJ讀取TransactionAspect的定義，象第（4）步一樣，發(fā)現(xiàn)了發(fā)現(xiàn)了一個(gè)pointcut--bankMethods()。
- AspectJ繼續(xù)讀取AuthAspect的定義，發(fā)現(xiàn)了一個(gè)around()。這次AspectJ把"Begin Transaction"和"End Transaction"兩段代碼加在Bank.deposit和Bank. withdraw兩個(gè)方法的執(zhí)行前后。達(dá)到的效果就如同Code 2.3所示。
如何驗(yàn)證這一點(diǎn)？您可以到 http://www.eclipse.org/aspectj/下載安裝AspectJ，編譯里面的Sample，把編譯結(jié)果反編譯一下，就可以看到AspetJ自動(dòng)生成的代碼。
我們看到，AspectJ是一種代碼自動(dòng)生成工具。你編寫一段通用的代碼，比如認(rèn)證方面的代碼，事務(wù)方面的代碼，然后根據(jù)AspectJ語法定義一套代碼生成規(guī)則（aspect定義），AspectJ就會(huì)幫助你自動(dòng)把這段通用代碼分布到對(duì)應(yīng)的代碼里面去，簡(jiǎn)單快捷，算無遺策。
無獨(dú)有偶，一個(gè)著名的編譯器生成工具--Java Compiler Compiler (JavaCC)，也采用了非常相似的代碼生成機(jī)制。JavaCC允許你在語法定義規(guī)則文件中，加入你自己的Java代碼，用來處理讀入的各種語法元素。
AspectJ令你的代碼更精簡(jiǎn)，結(jié)構(gòu)更良好。AspectJ的好處，我就不多說了，網(wǎng)上很多精彩的文章探討AspectJ的各種用途。
下面介紹一個(gè)著名的代碼自動(dòng)生成器--xDoclet，和EJB Descriptor，AspectJ之間的聯(lián)系和比較。
5．xDoclet
我們知道，Doclet用來生成Javadoc，xDoclet是Doclet的擴(kuò)展，不僅僅能生成Javadoc，還能夠生成源代碼和配置信息等。
Doclet和xDoclet的工作原理，就是處理源代碼中的注釋中的tag，生成相應(yīng)的信息。這些tag都以@開頭，你可以自己定義tag和對(duì)tag的處理，生成自定義的信息。
（這里提一下Apache Maven Project。Maven是一種Project Build工具。用Maven進(jìn)行管理的項(xiàng)目，能夠同時(shí)生成Javadoc和XRef。XRef是Source Code Cross Reference。)
JBoss就利用xDoclet為EJB自動(dòng)生成EJB Home和EJB Object Interface源文件，和EJB Descriptor文件。
在Sourceforge.net上看到一個(gè)叫做Barter的開源項(xiàng)目，利用xDoclet為類方法生成AspectJ代碼。
請(qǐng)注意，EJB Descriptor和AspectJ都是把方方面面的Aspects集中在一處進(jìn)行管理，而xDoclet的思想是處理散布在源代碼中的各種tag。
xDoclet在生成EJB Descriptor和AspectJ等方面的應(yīng)用，正應(yīng)了中國(guó)的一句古話--分久必合，合久必分。
6．總結(jié)
開源項(xiàng)目的出現(xiàn)，打破了軟件技術(shù)領(lǐng)域的眾多壁壘，推動(dòng)軟件技術(shù)進(jìn)程的日新月異。
同時(shí)，一些新名詞，新概念也層出不窮，令人眼花繚亂，無所適從。其實(shí)，很多東西都是換湯不換藥，我們理解應(yīng)用這些新技術(shù)的時(shí)候，要抓住本質(zhì)，要破除迷信，破除任何人為的神秘感。
舉個(gè)例子，現(xiàn)在炒作的很熱的一些概念，"Web Service"，還有"Grid Computation"（網(wǎng)格計(jì)算），都是基于原有的各種技術(shù)發(fā)展出來的。媒體和技術(shù)文章不應(yīng)該人為地制造任何神秘感。
互聯(lián)網(wǎng)時(shí)代的權(quán)威，不是說出來的，而是做出來的。
另外，圍繞著一些有前途的新技術(shù)，總會(huì)出現(xiàn)大量的"快速入門手冊(cè)"，有些簡(jiǎn)直就是對(duì)該技術(shù)幫助文檔的翻譯，而且，有難度的地方?jīng)]有翻譯出來，大家都明白的地方翻譯得非常詳盡，詳盡到了沒有必要的地步。這種因?yàn)槭袌?chǎng)需求而產(chǎn)生的應(yīng)景時(shí)文，大量地出現(xiàn)在技術(shù)文章領(lǐng)域。
筆者對(duì)本文的期望是，決不迷信，決不重復(fù)。并試圖引入一種潔凈的，毫無廢話的文風(fēng)。筆者期待一針見血的駁斥和批評(píng)。
Enjoy it. J
Thanks.
關(guān)于作者
 |
|
|
|
王海龍 普通程序員。
Powered by Open Source。致力于做一個(gè)Architect，Solution Provider，Best Practice Provider。
希望有一天，有足夠的時(shí)間，精力和能力的時(shí)候，將把自己有限的一身所學(xué)的一點(diǎn)東西全部貢獻(xiàn)給Open Source Project。
你可以通過 buaawhl@sina.com與他聯(lián)系。
|
|