AOP 面向方編程(Aspect Oriented Programming)

在程序員的圈子里面,有一群人數很少但態度卻十分堅定的開發人員。當他們宣稱，真正的程序員會編寫自己的驅動程序。

因為如果不這樣，那么采用任何其他的方式都將會是瘋狂和缺乏技術理性的，并且還會承擔一些不必要的風險。 
 

在軟件行業的另一端，人們卻在為類似于面向方面編程（Aspect Oriented Programming即AOP）的技術歡呼雀躍。他們以非常嚴肅的態度說道，真正的程序員希望盡可能的保持多產，這樣才能穩住自己的飯碗。相對于對自己工作方式三天兩頭的革新，這些程序員們更希望能開發更多的程序和更為有效的對代碼進行重用。

AOP是從什么地方來的？

多年以來，面向對象（OO）時編程技術革新的先鋒，但是，即使是針對不同功能編寫分離代碼片段的面向對象思想也無法將程序開發人員從一遍遍重寫應用程序多個部分的煩惱中解脫出來。來自Xerox Palo Alto Research Lab（即PARC）的研究人員早在1990年開始就對面向對象思想的局限性進行了分析。他們研究出了一種新的編程思想，借助這一思想或許可以通過減少代碼重復模塊從而幫助開發人員提高工作效率。與此同時，美國Northeastern University的博士生Cristina Lopes和其同事也開始了類似的思考。最終，美國國防先進技術研究計劃署（Defense Advanced Research Projects Agency即DARPA）注意到了這項工作，并提供了科研經費，鼓勵將二者的工作成果結合起來。由此，AspectJ誕生了。它作為Java語言的一套擴展系統使得當今的程序員們現在就可以體驗AOP的思想。 Avanade公司的高級方案構架師Adam Magee認為，AOP的核心思想就是“將應用程序中的商業邏輯同對其提供支持的通用服務進行分離。”該公司是一架專注于微軟技術的集成商。 AOP的創業者們把這些通用服務稱之為“橫切關注點（crosscutting concerns）”，因為這些服務所提供的功能將橫貫應用程序的多個對象需求。將AOP應用到多個項目中的Magee也認為，“開發人員可以對橫切關注點進行檢測、審計、登陸、安全性檢查或異常處理。編寫這些服務的接口代碼將會非常耗費時間，并且開發人員要學會如何這樣做本身就已很長時間。”“這些事情將開發人員的精力從解決企業問題上面轉移開來——而后者才是價值之所在。這些麻煩將他們引到了鉆研復雜操作系統的艱難道路上。

優勢

AOP的目標就是要避免這些問題。它將編寫橫切關注點代碼的工作進行分離——也就是所謂的“方面（aspects）”——把他們從組織為商業邏輯的對象的編寫工作中分離出來，然后提供相應的功能構架。這樣一來，應用程序就可以使用各個方面所提供的功能而無需重新編譯或重新編寫任何代碼。

在一個應用程序有很多對象都需要相同橫切關注點，這一技術即著眼于通過幫助開發人員創建所需要的橫切關注點定義來為開發人員節省時間。如果要對每一個對象編寫一個登錄系統——AOP中所謂的“散射（scattering）”實踐——AOP的先行者們建議在項目的設計階段，開發人員就應當定義應用程序中每個對象的登錄需求，然后創建一個單獨的登錄工具執行該應用程序中任何所需的登錄操作。 AOP的支持者們認為，這樣的方式有幾個優點。第一，在定義應用程序對某種服務（例如登錄）的所有需求的時候，所花費的精力將使得該服務能夠被更好的定義，更好的被編寫代碼，并獲得更多的功能。這種方式還能夠處理在代碼涉及到多個功能的時候所出現的問題，例如改變某一個功能可能會影響到其它的功能，在AOP中把這樣的麻煩稱之為“糾結（tangling）”。

其次，在創建離散方面所進行的分析將有助于為開發團隊指定一位精于該項工作的專家，由此負責這項工作的最佳人選將可以有效利用自己的相關技能和經驗。第三個好處則是持久性的。標準的以對象為導向的項目開發中，不同的開發人員通常會為某項服務編寫相同的代碼，例如登錄。隨后他們會在自己的實施中進開發各自的登錄服務以滿足不同單個對象的需求。而通過創建一段單獨的代碼片段，AOP提供了解決這一問題的持久簡單的方案，這一方案強調了未來功能的重用性和易維護性：不需要在整個應用程序中一遍遍重新編寫登錄代碼，AOP使得僅僅編寫登錄方面（logging aspect）成為可能，并且可以在這之上為整個應用程序提供新的功能。所有的這些好處都是的需要編寫的代碼量大大縮減，由此節省了時間，控制了開發成本，并且能將資源投入到比編寫登錄程序更為有價值的活動中去。
 

AOP的工作原理

IBM的客戶經理Brad Kasell說道：“傳統上當你開始開發應用程序的時候，你從定義商業功能開始入手，即哪些應用程序需要完成的所有功能。”

“但總是項目涉及的所有開發人員都沒有編寫規范，因此開發人員們最終將會發現一個應用程序在不同的地方需要不同類型的登錄服務，因此需要在不同的時候一遍遍的編寫他們。”“AOP則意味開發人員最終能夠獲得這樣的機會，即提出一個問題：‘如何才能使得你只需編寫一次就可以讓這段代碼服務于整個應用程序？’” 因此，AOP項目的起點在于開發人員確認所有對象都會需要的功能。隨著對象的進一步開發，開發人員將能夠找出每個對象都需要的一個普遍的功能，即“橫切點”。這時，不同于在對象內部編寫登錄服務，開發人員將編寫一個“切點（point cut）”，這一“切點”將“織入（weaves）”到對象的方面（aspect）中。這樣的方式時的應用程序將有一些對象和一個單獨的代碼池所組成，在對象調用所需的服務視，這一代碼池將提供通用的服務。

如何進行編程

要把AOP引入到工作中來是比較簡單的，現在市面上已經有了很多種工具。在這一領域，開放源代碼軟件是主打。最初由PARC設計的AspectJ在2002年已經被轉手給Eclipse Foundation，它現在是最為流行的AOP工具。 AspectJ將其自身標榜為“同Java編程語言無縫集成的面向方面擴展”，它提供了新的語法來定義、創建和使用方面。AspectJ可以被引入到多個編程工具中。最為常見的AOP工具是AspectWerkz，這是兩位BEA員工所開發的，這一軟件在松散的GNU公共許可證下發布。

2005年1月，AspectJ和AspectWerkz達成協議，同意將二者的成果綜合到一起，取其精華創建一個單一的工具。像Jboss這樣的商用軟件制造商同樣提供AOP產品。這一企業所開發的JBoss AOP已經在2004年晚期發布，同樣提供了面向方面的框架和一個方面庫。在.NET的陣營中，事情的進展則要緩慢一些。2005年1月，微軟發布的Enterprise Library提供了7種不同的“應用程序塊（

application blocks）”。Avanade的Magee認為這些組件可以被認為是就方面，使用Visual Studio .Net. Loom中的屬性進行訪問則是另一個回事。但這些工具所采用的方法決不是統一的。AspectJ是對Java的擴展。反對陣營認為，對語言進行擴展存在與之俱來的麻煩，AOP應當通過使用XML元數據來進行部署，從而定義橫切點和所調用的對象。開發工具以及什么地方可以找到這些工具。

有限制條件么？

這些方法上的不一致和實際應用情況使得沒有主流IDE制造商將AOP作為產品工具中的“正式”部分。這也讓很多人感覺到盡管AOP的核心思想非常有用，但它仍然沒有成熟。“我相信AOP還不足以打入主流編程領域，因此很多人并不能確定如何才能將這一技術引入到日常的工作中去，” BEA技術辦公室的技術經理Michael Smith說道。“這是在主流和技術前沿之間的一塊中間地帶。” 這一理念正存在于這一中間地帶中，其真正的潛能在某種程度上仍然是未知的。開發顧問ThoughtWorks的咨詢師John Tirsen表示，它已經在多個項目中使用了AOP。但模塊化服務（modularising

services）的思想并非是全新的。“以前就有CORBA攔截機做過這樣的事情”，他說道。“更具爭議的問題在于它是否能夠用到橫切商業邏輯（cross-cutting business logic）上去。”

BEA的Smith同樣認可這一未被觸及的潛力。“沿著技術發展的道路我們可以認為或許你希望借助AOP來對中間件的運行方式進行調整，或許希望根據不同的商業規則在不同時間為不同的功能創建中間件層。盡管這種類型的工作聽起來很刺激，但沒有人能夠為這一技術的發布實施和廣泛采用提出一份時間表。 AOP的精靈正躍躍欲試，即將從瓶子里面跑出來。

“6個月以前，沒有人問我AOP，”Smith說道。“現在你可以在AOP討論會之中看到聽眾在我甚至沒有提到這一技術的情況下問到這一問題。無論你是否希望編寫自己的設備驅動程序，這都是一個明顯的信號，即AOP在將來的一段時間中值得人們去研究。

轉http://kekesoft.spaces.live.com/blog/