了解AOP

利用AOP分離軟件關注點

一個關注點(concern)就是一個特定的目的,一塊我們感興趣的區域。從技術的角度來說，一個典型的軟件系統包含一些核心的關注點和系統級的關注點。舉個例子來說，一個信用卡處理系統的核心關注點是借貸/存入處理，而系統級的關注點則是日志、事務完整性、授權、安全及性能問題等，許多關注點——我們叫它橫切關注點（crosscutting concerns）——會在多個模塊中出現，使用現有的編程方法，橫切關注點會橫越多個模塊，結果是使系統難以設計、理解、實現和演進。
AOP能夠比上述方法更好地分離系統關注點，從而提供模塊化的橫切關注點。
在這篇文章里，我首先會解釋橫切關注點在軟件系統中引起的問題，接著我會介紹AOP是怎樣解決橫切關注點問題的。
軟件編程方法的演進
在計算機科學的早期階段，開發人員使用簡單的機器級代碼來編程。不幸的是，程序員得花費更多時間來考慮一種特定機器的指令集而不是手中需要解決的問題本身。慢慢地，我們轉而使用允許對底層機器做某種抽象的高級語言。然后是結構化語言，我們可以把問題分解成一些必要的過程來完成任務。但是，隨著復雜程度的增加，我們又需要更適合的技術。面向對象的編程方式（OOP）使我們可以把系統看作是一批相互合作的對象。類允許我們把實現細節隱藏在接口下。多態性為相關概念提供公共的行為和接口，并允許特定的組件在無需訪問基礎實現的前提下改變特定行為。
編程方法和語言決定了我們和計算機交流的方式。每一種新的方法學都提出一種新的分解問題的方法：機器碼、偽代碼、過程和類等。每種新的方法學都使得從系統需求到編程概念的映射更加自然。編程方法學的發展讓我們可以建立更加復雜的系統，這名話反過來說也地，我們能夠建立更加復雜的系統是加為這些技術允許我們處理這種復雜度。
現在，大多數軟件項目都選擇OOP的編程方式。確實，OOP已經表明了它處理一般行為的能力，但是，我們將會看到（或許你已經感覺到了）：OOP不能很好地處理橫越多個——經常是不相關的——模塊的行為。相比之下，AOP填補了這個空白，它很可能會是編程方法學發展的一個里程碑。
把系統看作一批關注點
我們可以把一個復雜的系統看作是由多個關注點來組合實現的。一個典型的系統可能會包括幾個方面的關注點，如業務邏輯、性能，數據存儲、日志和調度信息、授權、安全、線程、錯誤檢查等，還有開發過程中的關注點，如易懂、易維護、易追查、易擴展等，圖1演示了由不同模塊實現的一批關注點組成一個系統。

圖2把需求比作一束穿過三棱鏡的光。我們讓需求之光通過鑒別關注點的三棱鏡，就會區別出每個關注點。

開發人員建立一個系統以滿足多個需求，我們可以大致地把這些需求分類為核心模塊級需求和系統組需求。很多系統級需求一般來說是相互獨立的，但它們一般都會橫切許多核心模塊。舉個例子來說，一個典型的企業應用包含許多橫切關注點，如驗證、日志、資源地、系統管理、性能及存儲管理等，每一個關注點都牽涉到幾個子系統，如存儲管理關注點會影響到所有的有狀態業務對象。
讓我們來看一個簡單的例子，考慮一個封裝了業務邏輯的類的實現框架：
public class SomeBusinessClass extends
otherBusinessClass{
//核心數據成員
//其它數據成員：日志流，保證數據完整性的標志位等
//重載基類的方法
public void performSomeOperation
(OperationInformation info)
//安全性驗證
//檢查傳入數據是否滿足協議
//鎖定對象以食品店當其他線程訪問時的數據完整性
//檢查緩存中是否為最新信息
//記錄操作開始執行時間
//執行核心操作
//記錄操作完成時間
//給對象解鎖
}
//一些類似操作
public void save(PersitanceStorage ps){
}
public void save(PersitanceStorage ps){
}
}
在上面的代碼中，我們注意到三個問題：首先，其它數據成員不是這個類的核心關注點；第二performSomeOperation()的實現做了許多核心操作之外的事，它要處理日志、驗證、線程安全、協議驗證和緩存管理等一些外圍操作，而且這些外圍操作同樣也會應用于其他類；第三，save（）和load（）執行的持久化操作是否構成這個類的核心是不清楚的．
橫切關注點的問題
雖然橫切關注點會跨越多個模塊，但當前的技術傾向于使用一維的方法學來處理這種需求，把對應需求的實現強行限制在一維的空間里．這個一維空間就是核心模塊級實現．其他需求的實現被嵌入在這個占統治地位的空間．換句話說，需求空間是一個n維空間，而實現空間是一維空間，這種不匹配導致了糟糕的需求到實現的映射。
表現
用當前方法學實現橫切關注點是不好的．它會帶來一些問題，我們可以大致把這些問題分為兩類。
代碼混亂：軟件系統中的模塊可能要同時兼顧幾個方面的需要．舉例來說，開發者經常要同時考慮業務邏輯、性能、同步，日志和安全等問題，兼顧各方面的需要導致相應關注點的實現元素同時出現，引起代碼混亂．
代碼分散：由于橫切關注點本來就涉及到多個模塊．相關實現也就得遍布在這些模塊里．如在一個使用了數據庫的系統里，性能問題就會影響所有訪問數據庫的模塊。這導致代碼分散在各處．
結果
混亂和分散的代碼會從多個方面影響系統的設計和開發：
可讀性差：同時實現幾個關注點模糊了不同關注點的實現，使得關注點與其實現之間的對應關系不明顯。
低產出：同時實現幾個關注點把開發人員的注意移到外圍關注點，導致生產效率降低．
低代碼重用率： 由于一個模塊實現多個關注點，因此其他需要類似功能的系統不能馬上使用該模塊．進一步降低了生產效率。
代碼質量差：混亂的代碼掩蓋了代碼中隱藏的問題。而且，由于同時要處理多個關注點．應該特別注意的關注點得不到應有的關注．
難以擴展：狹窄的視角和有限的資源總是產生僅注意當前關注點的設計．新的需求導致從新實現．由于實現不是模塊化的，就是說實現牽涉到多個模塊，為了新需求修改子系統可能會帶來數據的不一致，而且還需相當規模同測試來保證這些修改不會帶來bug。
當前解決方法
由于多數系統中都包含橫切關注點、自然的已經形成了一些技術來模塊化橫切關注點的實現，這些技術包括：混入類、設計模式和面向特定問題域的解決方式。
使用混入類，你可以推遲關注點的最終實現．基本類包含一個混入類的實例，允許系統的其他部分設置這個實例。舉個例子來說，實現業務邏輯的類包含一個混入的logger，系統的其他部分可以設置這個logger已得到合適的日志類型，比如logger可能被設置為使用文件系統或是消息中間件。在這種方式下，雖然日志的具體實現被推遲，基本類還是必須在所有寫日志的點調用日志操作和控制日志信息的代碼。
行為型設計模式，如Visitor和Template Method模式，也允許你推遲具體實現。但是也就像混入類一樣，操作的控制——調用visitor或template Method的邏輯——仍然留給了基本類。
面向特定問題域的解決方式，如框架和應用服務器，允許開發者用更模塊化的方式處理某些橫切關注點。比如E J B（Enterprise JavaBean）架構，可以處理安全、系統管理、性能和容器管理的持久化（container-managed persistence）等橫切關注點。B e a n與數據庫的映射，但是大多數情況下，開發者還是要了解存儲結構。這種方式下，你用基于XML的映射關系描述器來實現于數據持久化相關的橫切關注點。
面向特定問題域的解決方式提供了解決特定問題的專門機制，它的缺點是對于每一種這樣的解決方式開發人員都必須重新學習，另外，由于這種方式是特定問題域相關的，屬于特定問題域之外的橫切關注點需要特殊的對待。
設計師的兩難局面
好的系統設計師不僅會考慮當前需求，還會考慮到可能會有的需求以避免到處打補丁。這樣就存在一個問題預知將來是很困難的，如果你漏過了將來可能會有的橫切關注點的需求，你將會需要修改或甚至是重新實現系統的許多部分；從另一個角度來說，太過于關注不一定需要的需求會導致過分設計的、難以理解的、臃腫的系統。所以系統設計師處在這么一個兩難局面中：怎么設計算不了過分設計？應該寧可設計不足還是寧可過分設計？
舉個例子來說，設計師是否應該在系統中包含現在并不需要的日志機制？如果是的話，哪里是應該寫日志的點？日志應該記錄那些信息相似的例子還有關于性能的優化問題，我們很少能預知瓶頸的所在。常用的方法是建立系統，profile它，然后翻新系統以提高性能，這種方式可能會依照profiling而修改系統的很多部分。此外，隨著時間的流逝，由于使用方式的變化，可能還會產生新的瓶頸。類庫設計師的任務更困難，因為他很難設想出所有對類庫的使用方式。
總而言之，設計師很難顧及到系統可能需要處理的所有關注點。即使是在已經知道了需求的前提下，某些建立系統時需要的細節 也可能不能全部得到，整體設計就面臨著設計不足/過分設計的兩難局面。
AOP基礎
到目前為止的討論說明模塊化橫切關注點是有好處的。研究人員已經嘗試了多種方法來實現這個任務，這些方法有一個共同的主題：分離關注點。A O P是這些方法中的一種，它的目的是清晰的分離關注點來解決以上提到的問題。
AOP， 從其本質上講，使你可以用一種松散耦合的方式來實現獨立的關注點，然后 組合這些實現來建立最終系統、用它所建立的系統是使用松散偶合的，模塊化實現的橫切關注點來搭建的、與之對照 用OOP建立的系統則是用松散耦合的模塊化實現的一般關注點來實現的。在AOP中，這些模塊化單元叫“方面（aspect）”，而在OOP中，這些一般關注點的實現單元叫做類。
AOP 包括三個清晰的開發步驟：
方面分解：分解需求撮出橫切關注點。在這一步里，你把核心模塊級關注點和系統級的橫切關注點分離開來、就前面所提到的信用卡例子來說 你可以分解出三個關注點：核心的信用卡處理、日志和驗證。
關注點實現：各自獨立的實現這些關注點，還用上面信用卡的例子，你要實現信用卡處理單元、日志單元和驗證單元。
方面的重新組合：在這一步里，方面集成器通過創建一個模塊單元—一方面來指定重組的規則， 重組過程—一也叫織入（weaving）或結合（integrating）——則使用這些信息來構建最終系統、還拿信用卡的那個例子來說 你可以指定（用某種AOP的實現所提供的語言）每個操作的開始和結束需要記錄，并且每個操作在涉及到業務邏輯之前必須通過驗證。

AOP與OOP最重要的不同在于它處理橫切關注點的方式．在AOP中 每個關注點的實現都不知道其它關注點是否會“關注”它，如信用卡處理模塊并不知道其它的關注點實現正在為它做日志和驗證操作。它展示了一個從OOP轉化來的強大的開發范型。
注意：一個AOP實現可以借助其它編程范型作為它的基礎，從而原封不動的保留其基礎范型的優點。例如，AOP可以選擇OOP作為它的基礎范型，從而把OOP善于處理一股關注點的好處直接帶過來。用這樣一種實現，獨立的一般關注點可以使用OOP技術、這就像過程型語言是許多OOP語言的基礎一樣。
AOP語言剖析
就像其他編程范型的實現一樣，AOP的實現由兩部分組成：語言規范和實現。語言規范描述了語言的基礎單元和語法；語言實現則按照語言規范來驗證代碼的正確性，并把代碼轉成目標機器可執行的形式。這一節，我來解釋一下AOP組成部分。
AOP語言規范
從抽象的角度看來 一種AOP語言要說明下面兩個方面：
關注點的實現：把每個需求映射為代碼，然后，編譯器把它翻譯成可執行代碼。由于關注點的實現以指定過程的形式出現，你可以使用傳統語言如C、C＋＋、JAVA等。
織入規則規范：怎樣把獨立實現的關注點組合起來形成最終系統呢？為了這個目的 需要建立一種語言來指定組合不同的實現單元，以形成最終系統的規則。這種指定織入規則的語言可以是實現語言的擴展，也可以是一種完全不同的語言。
AOP語言的實現
AOP的編譯器執行兩步操作：
l 組裝關注點
2 組裝結果轉成可執行代碼。
AOP實現可以用多種方式實現織入， 包括源碼到源碼的轉換、它預處理每個方面的源碼，產生織入過的源碼，然后把織入過的源碼交給基礎語言的編譯器， 產生最終可執行代碼。比如 使用這種方式，一個基于Java的AOP實現可以先把不同的方面轉化成Java源代碼，然后讓Java編譯器把它轉化成字節碼．也可以直接在字節碼級別執行織入； 畢竟 字節碼本身也是一種源碼。此外，底層的執行系統—一Java虛擬機—一也可以設計為支持AOP的�；�于Java的AOP實現如果使用這種方式的話，虛擬機可以先裝入織入規則，然后對后來裝入的類都應用這種規則、也就是說，它可以執行just－in－time的方面織入。
AOP的好處
AOP可幫助我們解決上面提到的代碼混亂和代碼分散所帶來的問題，它還有一些別的好處：
模塊化橫切關注點：AOP用最小的耦合處理每個關注點，使得即使是橫切關注點也是模塊化的。這樣的實現產生的系統，其代碼的冗余小。模塊化的實現還使得系統容易理解和維護。
系統容易擴展：由于方面模塊根本不知道橫切關注點，所以很容易通過建立新的方面加入新的功能．另外，當你往系統中加入新的模塊時，已有的方面自動橫切進來，使系統易于擴展。
設計決定的遲綁定：還記得設計師的兩難局面嗎？使用AOP 設計師可以推遲為將來的需求作決定，因為他可以把這種需求作為獨立的方面很容易地實現。
更好的代碼重用性：AOP把每個方面實現為獨立的模塊， 模塊之間是松散耦合的．舉例來說，你可以用另外一個獨立的日志寫入器方面來替換當前的，用于把日志寫入數據庫，以滿足不同的日志寫入要求。松散藕合的實現通常意味著更好的代碼重用性，AOP在使系統實現松散出合這一點上比OOP做得更好。
AspectJ：一個Java的AOP實現
AspectJ是一個可免費獲得的、由施樂公司帕洛阿爾托研究中心（Xerox PARC）開發的、Java的AOP實現。它使用java作為單個關注點的實現語言，并擴展Java以指定織入規則．
另外，AspectJ允許以多種方式用方面和類建立新的方面，你可以引入新的數據成員和方法或是聲明一個新的類來繼承和實現另外的類或接口。
AspectJ的織入器——AspectJ的編譯器——負責把不同的方面組合在一起，由于AspectJ編譯器建立的最終系統是Java字節碼，因此，它可以運行在任何符合Java標準的虛擬機上。而且，AspectJ還提供了一些工具，例如調試器和Java IDE集成等。
我需要AOP嗎？
AOP僅僅是解決設計上的缺點嗎？在AOP里，每個關注點的實現的并不知道是否有其它關注點關注它，這是AOP和OOP的主要區別。在AOP里，組合的流向是從橫切關注點到主關注點，而OOP則相反。但是，OOP可以和AOP很好地共存。比如，你可以使用一個混入類來做組合，既可以用AOP實現，也可以用OOP實現，這取決你對AOP的接受程度，在這兩種情況下，實現橫切關注點的混入類實現都無需知道它自己是被用在類中還是被用在方面中。舉個例子來說，你可以把一個日志寫入器接口用作某些類的混入類或是用作一個日志方面，因而，從OOP到AOP 是漸進的。

了解AOP
在這篇文章里，你看到了橫切關系帶來的問題，這些問題當前解決方法以及這些方法的缺點。你也看到了AOP 是怎樣克服這些缺點的，AOP的編程方式試圖�？旎瘷M切關注點的實現，提供了一個更好更快的軟件開發方式。
如果你的系統中涉及到多個橫切關注點，你可以考慮進一步了解AOP，了解它的實現和它的好處。AOP很可能會是編程方式的一個里程碑。