AOP技術(shù)基礎1、
引言2、AOP技術(shù)基礎
3、
Java平臺AOP技術(shù)研究4、
.Net平臺AOP技術(shù)研究2.1 AOP技術(shù)起源
AOP技術(shù)的誕生并不算晚，早在1990年開(kāi)始，來(lái)自Xerox Palo Alto Research Lab（即PARC）的研究人員就對面向對象思想的局限性進(jìn)行了分析。他們研究出了一種新的編程思想，借助這一思想或許可以通過(guò)減少代碼重復模塊從而幫助開(kāi)發(fā)人員提高工作效率。隨著(zhù)研究的逐漸深入，AOP也逐漸發(fā)展成一套完整的程序設計思想，各種應用AOP的技術(shù)也應運而生。
AOP技術(shù)在Java平臺下是最先得到應用的。就在PARC對于面向方面編程進(jìn)行研究的同時(shí)，美國Northeastern University的博士生Cristina Lopes和其同事也開(kāi)始了類(lèi)似的思考。最終，美國國防先進(jìn)技術(shù)研究計劃署（Defense Advanced Research Projects Agency即DARPA）注意到了這項工作，并提供了科研經(jīng)費，鼓勵將二者的工作成果結合起來(lái)。他們通過(guò)定義一套Java語(yǔ)言的擴展系統，使開(kāi)發(fā)者可以方便的進(jìn)行面向方面的開(kāi)發(fā)，這套擴展系統被稱(chēng)為AspectJ。之后，AspectJ在2002年被轉讓給Eclipse Foundation，從而成為在開(kāi)源社區中AOP技術(shù)的先鋒，也是目前最為流行的AOP工具。
AspectWerkz則是基于Java的動(dòng)態(tài)的、輕量級AOP框架。AspectWerkz仍然是開(kāi)源社區中的產(chǎn)品，由BEA System提供贊助，開(kāi)發(fā)者則是BEA的兩名員工Jonas Bonér和Alexandre Vasseur。最近版本是AspectWerkz 2.0。2005年1月，AspectJ和AspectWerkz達成協(xié)議，同意將二者的成果綜合到一起，取其精華創(chuàng )建一個(gè)單一的工具。他們合作的第一個(gè)發(fā)布版本為AspectJ 5，它擴展了AspectJ語(yǔ)言，以支持基于A(yíng)nnotation開(kāi)發(fā)風(fēng)格而又支持類(lèi)似AspectJ代碼風(fēng)格。AspectJ 5也為Java 5的語(yǔ)言特性提供完全的AOP支持。
在Java陣營(yíng)中，商用軟件制造商JBoss在其2004年推出的JBoss 4.0中，引入了AOP框架和組件。在JBoss 4.0中，用戶(hù)可以在JBoss應用服務(wù)器外部單獨使用JBoss AOP，該版本為JBoss AOP 1.0，是在2004年10月發(fā)布的。在2005年，JBoss AOP框架又發(fā)布了1.3.0版本，新版本對加載期織入（Weev）和切點(diǎn)（point cut）匹配的性能做了很大的優(yōu)化，使應用程序的啟動(dòng)時(shí)間大大縮短。
作為輕型的Framework，Spring在開(kāi)發(fā)輕量級的J2EE時(shí)，應用是非常廣泛的。它通過(guò)IoC模式（Inversion of Control，控制反轉模式）來(lái)實(shí)現AOP，通常被稱(chēng)為Spring AOP。在2004年，被作為Spring框架的擴展而發(fā)布，目前版本已更新到1.1.3。Spring AOP作為一種非侵略性的，輕型的AOP框架，開(kāi)發(fā)者無(wú)需使用預編譯器或其他的元標簽，在Java程序中應用AOP。目前，AOP的功能完全集成到了Spring事務(wù)管理、日志和其他各種特性的上下文中。
在.Net的陣營(yíng)中，AOP技術(shù)的應用遠不如Java陣營(yíng)對AOP的關(guān)注。2005年1月，微軟發(fā)布的Enterprise Library提供了7種不同的“應用程序塊（application blocks）”。有個(gè)別專(zhuān)家認為，這些組件可以被認為是方面。但該觀(guān)點(diǎn)并未得到一致的認同。事實(shí)上，在.Net平臺下，推動(dòng)AOP技術(shù)發(fā)展的原動(dòng)力并非微軟，而是開(kāi)源社區。雖然，微軟的技術(shù)專(zhuān)家們亦然聽(tīng)到了在.Net Framework中增加AOP技術(shù)的群眾呼聲，但作為如此巨大的軟件公司，要讓它靈活地轉變戰略方向，顯然是不太現實(shí)的。正因為此，才賜予了開(kāi)源社區在A(yíng)OP技術(shù)的研究與探索上一個(gè)巨大的發(fā)展空間。
與Java陣營(yíng)中的AOP技術(shù)不同，目前在.Net平臺下的各種AOP工具，基本上還停留在實(shí)驗室階段。但一些在技術(shù)上領(lǐng)先且逐漸成熟的AOP產(chǎn)品，也在開(kāi)源社區中漸露崢嶸。這其中主要包括Aspect#，AspectDNG，Eos AOP等。
Aspect#是基于Castle動(dòng)態(tài)代理技術(shù)來(lái)實(shí)現的。Castle源于A(yíng)pache Avalon項目，其目的在于實(shí)現一個(gè)輕量級的IoC容器。Aspect#于2005年6月被收錄為Castle的其中一個(gè)子項目。它是針對CLI（.Net和Mono）實(shí)現的AOP框架，利用了反射、代理等機制。目前的Aspect#版本為2.1.1。
AspectDNG目前的版本為0.7，仍然處于beta版的階段。它的實(shí)現技術(shù)是基于rail的靜態(tài)織入。Rail屬于IL級別下的代碼織入，它自定義的一套xml格式的ILML語(yǔ)言，能夠將原有的程序集拆散成ILML格式，以便于對靜態(tài)程序集進(jìn)行修改和擴展，從而達到靜態(tài)織入的目的。因為AspectDNG是屬于IL級別下的代碼織入，因此在.Net平臺下，并不受具體的編程語(yǔ)言限制。
Eos AOP與AspectDNG一樣，仍然采用靜態(tài)織入的方式，但從語(yǔ)法定義上，它更近似于A(yíng)spectJ關(guān)于A(yíng)OP的實(shí)現。它擴展了C#語(yǔ)法，引入了aspect、introduce、before、after等關(guān)鍵字，并且提供了專(zhuān)用的Eos編譯器。Eos項目是于2004年9月開(kāi)始啟動(dòng)，2005年6月推出的0.3.3版本為最新版本，主要的開(kāi)發(fā)人員為Hridesh Rajan和Kevin Sullivan。前者為Virginia大學(xué)計算機系的研究生，Eos項目最初是由Hridesh Rajan提出的；而后者則為該計算機系的副教授（Associate Professor）。所以自Eos誕生之初，就帶有濃厚的學(xué)院派特色。
從AOP技術(shù)的整體發(fā)展來(lái)看，高性能、穩定、可擴展、易用的AOP框架是其趨勢與目標。從上述對各種AOP技術(shù)的分析來(lái)看，AOP技術(shù)無(wú)疑是具有共同特點(diǎn)的，而各種實(shí)現技術(shù)就是圍繞著(zhù)這些共性深入與延伸。接下來(lái)，我將概要地介紹AOP的本質(zhì)，以及它的技術(shù)要素。
2.2 AOP技術(shù)本質(zhì)
2.2.1 技術(shù)概覽
AOP（Aspect-Oriented Programming，面向方面編程），可以說(shuō)是OOP（Object-Oriented Programing，面向對象編程）的補充和完善。OOP引入封裝、繼承和多態(tài)性等概念來(lái)建立一種對象層次結構，用以模擬公共行為的一個(gè)集合。當我們需要為分散的對象引入公共行為的時(shí)候，OOP則顯得無(wú)能為力。也就是說(shuō)，OOP允許你定義從上到下的關(guān)系，但并不適合定義從左到右的關(guān)系。例如日志功能。日志代碼往往水平地散布在所有對象層次中，而與它所散布到的對象的核心功能毫無(wú)關(guān)系。對于其他類(lèi)型的代碼，如安全性、異常處理和透明的持續性也是如此。這種散布在各處的無(wú)關(guān)的代碼被稱(chēng)為橫切（cross-cutting）代碼，在OOP設計中，它導致了大量代碼的重復，而不利于各個(gè)模塊的重用。
而AOP技術(shù)則恰恰相反，它利用一種稱(chēng)為“橫切”的技術(shù)，剖解開(kāi)封裝的對象內部，并將那些影響了多個(gè)類(lèi)的公共行為封裝到一個(gè)可重用模塊，并將其名為“Aspect”，即方面。所謂“方面”，簡(jiǎn)單地說(shuō)，就是將那些與業(yè)務(wù)無(wú)關(guān)，卻為業(yè)務(wù)模塊所共同調用的邏輯或責任封裝起來(lái)，便于減少系統的重復代碼，降低模塊間的耦合度，并有利于未來(lái)的可操作性和可維護性。AOP代表的是一個(gè)橫向的關(guān)系，如果說(shuō)“對象”是一個(gè)空心的圓柱體，其中封裝的是對象的屬性和行為；那么面向方面編程的方法，就仿佛一把利刃，將這些空心圓柱體剖開(kāi)，以獲得其內部的消息。而剖開(kāi)的切面，也就是所謂的“方面”了。然后它又以巧奪天功的妙手將這些剖開(kāi)的切面復原，不留痕跡。
使用“橫切”技術(shù)，AOP把軟件系統分為兩個(gè)部分：核心關(guān)注點(diǎn)和橫切關(guān)注點(diǎn)。業(yè)務(wù)處理的主要流程是核心關(guān)注點(diǎn)，與之關(guān)系不大的部分是橫切關(guān)注點(diǎn)。橫切關(guān)注點(diǎn)的一個(gè)特點(diǎn)是，他們經(jīng)常發(fā)生在核心關(guān)注點(diǎn)的多處，而各處都基本相似。比如權限認證、日志、事務(wù)處理。Aop 的作用在于分離系統中的各種關(guān)注點(diǎn)，將核心關(guān)注點(diǎn)和橫切關(guān)注點(diǎn)分離開(kāi)來(lái)。正如Avanade公司的高級方案構架師Adam Magee所說(shuō)，AOP的核心思想就是“將應用程序中的商業(yè)邏輯同對其提供支持的通用服務(wù)進(jìn)行分離。”
實(shí)現AOP的技術(shù)，主要分為兩大類(lèi)：一是采用動(dòng)態(tài)代理技術(shù)，利用截取消息的方式，對該消息進(jìn)行裝飾，以取代原有對象行為的執行；二是采用靜態(tài)織入的方式，引入特定的語(yǔ)法創(chuàng )建“方面”，從而使得編譯器可以在編譯期間織入有關(guān)“方面”的代碼。然而殊途同歸，實(shí)現AOP的技術(shù)特性卻是相同的，分別為：
1、join point（連接點(diǎn)）：是程序執行中的一個(gè)精確執行點(diǎn)，例如類(lèi)中的一個(gè)方法。它是一個(gè)抽象的概念，在實(shí)現AOP時(shí)，并不需要去定義一個(gè)join point。
2、point cut（切入點(diǎn)）：本質(zhì)上是一個(gè)捕獲連接點(diǎn)的結構。在A(yíng)OP中，可以定義一個(gè)point cut，來(lái)捕獲相關(guān)方法的調用。
3、advice（通知）：是point cut的執行代碼，是執行“方面”的具體邏輯。
4、aspect（方面）：point cut和advice結合起來(lái)就是aspect，它類(lèi)似于OOP中定義的一個(gè)類(lèi)，但它代表的更多是對象間橫向的關(guān)系。
5、introduce（引入）：為對象引入附加的方法或屬性，從而達到修改對象結構的目的。有的AOP工具又將其稱(chēng)為mixin。
上述的技術(shù)特性組成了基本的AOP技術(shù)，大多數AOP工具均實(shí)現了這些技術(shù)。它們也可以是研究AOP技術(shù)的基本術(shù)語(yǔ)。
2.2.2 橫切技術(shù)
“橫切”是AOP的專(zhuān)有名詞。它是一種蘊含強大力量的相對簡(jiǎn)單的設計和編程技術(shù)，尤其是用于建立松散耦合的、可擴展的企業(yè)系統時(shí)。橫切技術(shù)可以使得AOP在一個(gè)給定的編程模型中穿越既定的職責部分（比如日志記錄和性能優(yōu)化）的操作。
如果不使用橫切技術(shù)，軟件開(kāi)發(fā)是怎樣的情形呢？在傳統的程序中，由于橫切行為的實(shí)現是分散的，開(kāi)發(fā)人員很難對這些行為進(jìn)行邏輯上的實(shí)現或更改。例如，用于日志記錄的代碼和主要用于其它職責的代碼纏繞在一起。根據所解決的問(wèn)題的復雜程度和作用域的不同，所引起的混亂可大可小。更改一個(gè)應用程序的日志記錄策略可能涉及數百次編輯——即使可行，這也是個(gè)令人頭疼的任務(wù)。
在A(yíng)OP中，我們將這些具有公共邏輯的，與其他模塊的核心邏輯糾纏在一起的行為稱(chēng)為“橫切關(guān)注點(diǎn)（Crosscutting Concern）”，因為它跨越了給定編程模型中的典型職責界限。
2.2.2.1 橫切關(guān)注點(diǎn)
一個(gè)關(guān)注點(diǎn)（concern）就是一個(gè)特定的目的，一塊我們感興趣的區域，一段我們需要的邏輯行為。從技術(shù)的角度來(lái)說(shuō)，一個(gè)典型的軟件系統包含一些核心的關(guān)注點(diǎn)和系統級的關(guān)注點(diǎn)。舉個(gè)例子來(lái)說(shuō)，一個(gè)信用卡處理系統的核心關(guān)注點(diǎn)是借貸/存入處理，而系統級的關(guān)注點(diǎn)則是日志、事務(wù)完整性、授權、安全及性能問(wèn)題等，許多關(guān)注點(diǎn)——即橫切關(guān)注點(diǎn)（crosscutting concerns）——會(huì )在多個(gè)模塊中出現。如果使用現有的編程方法，橫切關(guān)注點(diǎn)會(huì )橫越多個(gè)模塊，結果是使系統難以設計、理解、實(shí)現和演進(jìn)。AOP能夠比上述方法更好地分離系統關(guān)注點(diǎn)，從而提供模塊化的橫切關(guān)注點(diǎn)。
例如一個(gè)復雜的系統，它由許多關(guān)注點(diǎn)組合實(shí)現，如業(yè)務(wù)邏輯、性能，數據存儲、日志和調度信息、授權、安全、線(xiàn)程、錯誤檢查等，還有開(kāi)發(fā)過(guò)程中的關(guān)注點(diǎn)，如易懂、易維護、易追查、易擴展等，圖2.1演示了由不同模塊實(shí)現的一批關(guān)注點(diǎn)組成一個(gè)系統。
圖2.1 把模塊作為一批關(guān)注點(diǎn)來(lái)實(shí)現
通過(guò)對系統需求和實(shí)現的識別，我們可以將模塊中的這些關(guān)注點(diǎn)分為：核心關(guān)注點(diǎn)和橫切關(guān)注點(diǎn)。對于核心關(guān)注點(diǎn)而言，通常來(lái)說(shuō)，實(shí)現這些關(guān)注點(diǎn)的模塊是相互獨立的，他們分別完成了系統需要的商業(yè)邏輯，這些邏輯與具體的業(yè)務(wù)需求有關(guān)。而對于日志、安全、持久化等關(guān)注點(diǎn)而言，他們卻是商業(yè)邏輯模塊所共同需要的，這些邏輯分布于核心關(guān)注點(diǎn)的各處。在A(yíng)OP中，諸如這些模塊，都稱(chēng)為橫切關(guān)注點(diǎn)。應用AOP的橫切技術(shù)，關(guān)鍵就是要實(shí)現對關(guān)注點(diǎn)的識別。
如果將整個(gè)模塊比喻為一個(gè)圓柱體，那么關(guān)注點(diǎn)識別過(guò)程可以用三棱鏡法則來(lái)形容，穿越三棱鏡的光束（指需求），照射到圓柱體各處，獲得不同顏色的光束，最后識別出不同的關(guān)注點(diǎn)。如圖2.2所示：
圖2.2 關(guān)注點(diǎn)識別：三棱鏡法則
上圖識別出來(lái)的關(guān)注點(diǎn)中，Business Logic屬于核心關(guān)注點(diǎn)，它會(huì )調用到Security，Logging，Persistence等橫切關(guān)注點(diǎn)。
public class BusinessLogic
{
public void SomeOperation()
{
//驗證安全性；Securtity關(guān)注點(diǎn)；
//執行前記錄日志；Logging關(guān)注點(diǎn)；
DoSomething();
//保存邏輯運算后的數據；Persistence關(guān)注點(diǎn)；
//執行結束記錄日志；Logging關(guān)注點(diǎn)；
}
}
AOP的目的，就是要將諸如Logging之類(lèi)的橫切關(guān)注點(diǎn)從BusinessLogic類(lèi)中分離出來(lái)。利用AOP技術(shù)，可以對相關(guān)的橫切關(guān)注點(diǎn)封裝，形成單獨的“aspect”。這就保證了橫切關(guān)注點(diǎn)的復用。由于BusinessLogic類(lèi)中不再包含橫切關(guān)注點(diǎn)的邏輯代碼，為達到調用橫切關(guān)注點(diǎn)的目的，可以利用橫切技術(shù)，截取BusinessLogic類(lèi)中相關(guān)方法的消息，例如SomeOperation()方法，然后將這些“aspect”織入到該方法中。例如圖2.3：
圖2.3 將橫切關(guān)注點(diǎn)織入到核心關(guān)注點(diǎn)中
通過(guò)利用AOP技術(shù)，改變了整個(gè)系統的設計方式。在分析系統需求之初，利用AOP的思想，分離出核心關(guān)注點(diǎn)和橫切關(guān)注點(diǎn)。在實(shí)現了諸如日志、事務(wù)管理、權限控制等橫切關(guān)注點(diǎn)的通用邏輯后，開(kāi)發(fā)人員就可以專(zhuān)注于核心關(guān)注點(diǎn)，將精力投入到解決企業(yè)的商業(yè)邏輯上來(lái)。同時(shí)，這些封裝好了的橫切關(guān)注點(diǎn)提供的功能，可以最大限度地復用于商業(yè)邏輯的各個(gè)部分，既不需要開(kāi)發(fā)人員作特殊的編碼，也不會(huì )因為修改橫切關(guān)注點(diǎn)的功能而影響具體的業(yè)務(wù)功能。
為了建立松散耦合的、可擴展的企業(yè)系統，AOP應用到的橫切技術(shù)，通常分為兩種類(lèi)型：動(dòng)態(tài)橫切和靜態(tài)橫切。
2.2.2.2 動(dòng)態(tài)橫切
動(dòng)態(tài)橫切是通過(guò)切入點(diǎn)和連接點(diǎn)在一個(gè)方面中創(chuàng )建行為的過(guò)程，連接點(diǎn)可以在執行時(shí)橫向地應用于現有對象。動(dòng)態(tài)橫切通常用于幫助向對象層次中的各種方法添加日志記錄或身份認證。在很多應用場(chǎng)景中，動(dòng)態(tài)橫切技術(shù)基本上代表了AOP。
動(dòng)態(tài)橫切技術(shù)的核心主要包括join point（連接點(diǎn)），point cut（切入點(diǎn)），advice（通知）和aspect（方面）。在前面，我已經(jīng)概要地介紹了這些術(shù)語(yǔ)分別代表的含義。接下來(lái)，我將以一個(gè)具體的實(shí)例來(lái)進(jìn)一步闡述它們在A(yíng)OP動(dòng)態(tài)橫切中實(shí)現的意義。
考慮一個(gè)電子商務(wù)系統，需要對訂單進(jìn)行添加、刪除等管理操作。毫無(wú)疑問(wèn)，在實(shí)際的應用場(chǎng)景中，這些行為應與權限管理結合，只有獲得授權的用戶(hù)方能夠實(shí)施這些行為。采用傳統的設計方法，其偽代碼如下：
public class OrderManager
{
private ArrayList m_Orders;
public OrderManager()
{
m_Orders = new ArrayList();
}
public void AddOrder(Order order)
{
if (permissions.Verify(Permission.ADMIN))
{
m_Orders.Add(order);
}
}
public void RemoveOrder(Order order)
{
if (permissions.Verify(Permission.ADMIN))
{
m_Orders.Remove(order);
}
}
}
同樣的，在該電子商務(wù)系統中，還需要對商品進(jìn)行管理，它采用了同樣的授權機制：
public class ProductManager
{
private ArrayList m_Products;
public ProductManager()
{
m_Products = new ArrayList();
}
public void AddProduct(Product product)
{
if (permissions.Verify(Permission.ADMIN))
{
m_Products.Add(product);
}
}
public void RemoveProduct(Product product)
{
if (permissions.Verify(Permission.ADMIN))
{
m_Products.Remove(product);
}
}
}
如此以來(lái)，在整個(gè)電子商務(wù)系統中，核心業(yè)務(wù)包括訂單管理和商品管理，它們都需要相同的權限管理，如圖2.4所示：
圖2.4 電子商務(wù)系統的權限驗證實(shí)現
毫無(wú)疑問(wèn)，利用AOP技術(shù)，我們可以分離出系統的核心關(guān)注點(diǎn)和橫切關(guān)注點(diǎn)，從橫向的角度，截取業(yè)務(wù)管理行為的內部消息，以達到織入權限管理邏輯的目的。當執行AddOrder()等方法時(shí)，系統將驗證用戶(hù)的權限，調用橫切關(guān)注點(diǎn)邏輯，因此該方法即為AOP的join point。對于電子商務(wù)系統而言，每個(gè)需要權限驗證的方法都是一個(gè)單獨的join point。由于權限驗證將在每個(gè)方法執行前執行，所以對于這一系列join point，只需要定義一個(gè)point cut。當系統執行到j(luò )oin point處時(shí)，將根據定義去查找對應的point cut，然后執行這個(gè)橫切關(guān)注點(diǎn)需要實(shí)現的邏輯，即advice。而point cut和advice，就組合成了一個(gè)權限管理aspect。
圖2.5 AOP動(dòng)態(tài)橫切的技術(shù)實(shí)現
由于aspect是一個(gè)封裝的對象，我們可以定義這樣一個(gè)aspect：
private static aspect AuthorizationAspect{……}
然后在這個(gè)aspect中定義point cut，在point cut中，定義了需要截取上下文消息的方法，例如：
private pointcut authorizationExecution():
execution(public void OrderManager.AddOrder(Order)) ||
execution(public void OrderManager.DeleteOrder(Order)) ||
execution(public void ProductManager.AddProduct(Product)) ||
execution(public void ProductManager.DeleteProduct(Product));
由于權限驗證是在訂單管理方法執行之前完成，因此在before advice中，定義權限檢查：
before(): authorizationExecution()
{
if !(permissions.Verify(Permission.ADMIN))
{
throw new UnauthorizedException();
}
}
通過(guò)定義了這樣一個(gè)完整的aspect，當系統調用OrderManager或ProductManager的相關(guān)方法時(shí)，就觸發(fā)了point cut，然后調用相應的advice邏輯。如此以來(lái)，OrderManager和ProductManager模塊就與權限管理模塊完全解除了依賴(lài)關(guān)系，同時(shí)也消除了傳統設計中不可避免的權限判斷的重復代碼。這對于建立一個(gè)松散耦合、可擴展的系統軟件是非常有利的。
2.2.2.3 靜態(tài)橫切
靜態(tài)橫切和動(dòng)態(tài)橫切的區別在于它不修改一個(gè)給定對象的執行行為。相反，它允許通過(guò)引入附加的方法字段和屬性來(lái)修改對象的結構。此外，靜態(tài)橫切可以把擴展和實(shí)現附加到對象的基本結構中。在A(yíng)OP實(shí)現中，通常將靜態(tài)橫切稱(chēng)為introduce或者mixin。
靜態(tài)橫切在A(yíng)OP技術(shù)中，受到的關(guān)注相對較少。事實(shí)上，這一技術(shù)蘊含的潛力是巨大的。使用靜態(tài)橫切，架構師和設計者能用一種真正面向對象的方法有效地建立復雜系統的模型。靜態(tài)橫切允許您不用創(chuàng )建很深的層次結構，以一種本質(zhì)上更優(yōu)雅、更逼真于現實(shí)結構的方式，插入跨越整個(gè)系統的公共行為。尤其是當開(kāi)發(fā)應用系統時(shí)，如果需要在不修改原有代碼的前提下，引入第三方產(chǎn)品和API庫，則靜態(tài)橫切技術(shù)將發(fā)揮巨大的作用。
舉例來(lái)說(shuō)，當前已經(jīng)實(shí)現了一個(gè)郵件收發(fā)系統，其中類(lèi)Mail完成了收發(fā)郵件的功能。但在產(chǎn)品交付后，發(fā)現該系統存在缺陷，在收發(fā)郵件時(shí)，未曾實(shí)現郵件地址的驗證功能?，F在，第三方產(chǎn)品已經(jīng)提供了驗證功能的接口IValidatable：
public interface IValidatable
{
bool ValidateAddress();
}
我們可以利用設計模式中的Adapter模式，來(lái)完成對第三方產(chǎn)品API的調用。我們可以定義一個(gè)新的類(lèi)MailAdapter，該類(lèi)實(shí)現了IValidatable接口，同時(shí)繼承了Mail類(lèi)：
public class MailAdapter:Mail,IValidatable
{
public bool ValidateAddress()
{
if(this.getToAddress() != null)
{
return true;
}
else
{
return false;
}
}
}
通過(guò)引入MailAdapter類(lèi)，原來(lái)Mail對象完成的操作，將全部被MailAdapter對象取代。然而，此種實(shí)現方式雖然能解決引入新接口的問(wèn)題，但類(lèi)似下面的代碼，卻是無(wú)法編譯通過(guò)的：
Mail mail = new Mail();
IValidatable validate = ((IValidatable)mail).ValidateAddress();
必須將第一行代碼作如下修改：
Mail mail = new MailAdapter();
利用AOP的靜態(tài)橫切技術(shù)，可以將IValidatable接口織入到原有的Mail類(lèi)中，這是一種非常形象的introduce功能，其實(shí)現仍然是在aspect中完成：
import com.acme.validate.Validatable;
public aspect MailValidateAspect
{
declare parents: Mail implements IValidatable;
public boolean Mail.validateAddress()
{
if(this.getToAddress() != null)
{
return true;
}
else
{
return false;
}
}
}
靜態(tài)橫切的方法，并沒(méi)有引入類(lèi)似MailAdapter的新類(lèi)，而是通過(guò)定義的MailValidateAspect方面，利用橫切技術(shù)為Mail類(lèi)introduce了新的方法ValidateAddress()，從而實(shí)現了Mail的擴展。因此如下的代碼完全可行。
Mail mail = new Mail();
IValidatable validate = ((IValidatable)mail).ValidateAddress();
2.3 AOP技術(shù)的優(yōu)勢
AOP技術(shù)的優(yōu)勢是顯而易見(jiàn)的。在面向對象的世界里，人們提出了各種方法和設計原則來(lái)保障系統的可復用性與可擴展性，以期建立一個(gè)松散耦合、便于擴展的軟件系統。例如GOF提出的“設計模式”，為我們提供了設計的典范與準則。設計模式通過(guò)最大程度的利用面向對象的特性，諸如利用繼承、多態(tài)，對責任進(jìn)行分離、對依賴(lài)進(jìn)行倒置，面向抽象，面向接口，最終設計出靈活、可擴展、可重用的類(lèi)庫、組件，乃至于整個(gè)系統的架構。在設計的過(guò)程中，通過(guò)各種模式體現對象的行為、暴露的接口、對象間關(guān)系、以及對象分別在不同層次中表現出來(lái)的形態(tài)。然而鑒于對象封裝的特殊性，“設計模式”的觸角始終在接口與抽象中大做文章，而對于對象內部則無(wú)能為力。
通過(guò)“橫切”技術(shù)，AOP技術(shù)就能深入到對象內部翻云覆雨，截取方法之間傳遞的消息為我所用。由于將核心關(guān)注點(diǎn)與橫切關(guān)注點(diǎn)完全隔離，使得我們能夠獨立的對“方面”編程。它允許開(kāi)發(fā)者動(dòng)態(tài)地修改靜態(tài)的OO模型，構造出一個(gè)能夠不斷增長(cháng)以滿(mǎn)足新增需求的系統，就象現實(shí)世界中的對象會(huì )在其生命周期中不斷改變自身，應用程序也可以在發(fā)展中擁有新的功能。
設計軟件系統時(shí)應用AOP技術(shù)，其優(yōu)勢在于：
（一）在定義應用程序對某種服務(wù)（例如日志）的所有需求的時(shí)候。通過(guò)識別關(guān)注點(diǎn)，使得該服務(wù)能夠被更好的定義，更好的被編寫(xiě)代碼，并獲得更多的功能。這種方式還能夠處理在代碼涉及到多個(gè)功能的時(shí)候所出現的問(wèn)題，例如改變某一個(gè)功能可能會(huì )影響到其它的功能，在A(yíng)OP中把這樣的麻煩稱(chēng)之為“糾結（tangling）”。
（二）利用AOP技術(shù)對離散的方面進(jìn)行的分析將有助于為開(kāi)發(fā)團隊指定一位精于該項工作的專(zhuān)家。負責這項工作的最佳人選將可以有效利用自己的相關(guān)技能和經(jīng)驗。
（三）持久性。標準的面向對象的項目開(kāi)發(fā)中，不同的開(kāi)發(fā)人員通常會(huì )為某項服務(wù)編寫(xiě)相同的代碼，例如日志記錄。隨后他們會(huì )在自己的實(shí)施中分別對日志進(jìn)行處理以滿(mǎn)足不同單個(gè)對象的需求。而通過(guò)創(chuàng )建一段單獨的代碼片段，AOP提供了解決這一問(wèn)題的持久簡(jiǎn)單的方案，這一方案強調了未來(lái)功能的重用性和易維護性：不需要在整個(gè)應用程序中一遍遍重新編寫(xiě)日志代碼，AOP使得僅僅編寫(xiě)日志方面（logging aspect）成為可能，并且可以在這之上為整個(gè)應用程序提供新的功能。
總而言之，AOP技術(shù)的優(yōu)勢使得需要編寫(xiě)的代碼量大大縮減，節省了時(shí)間，控制了開(kāi)發(fā)成本。同時(shí)也使得開(kāi)發(fā)人員可以集中關(guān)注于系統的核心商業(yè)邏輯。此外，它更利于創(chuàng )建松散耦合、可復用與可擴展的大型軟件系統。
