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