?????是從網上轉載的。?
?????雖翻譯得很蹩腳，但因我打算2007年將英語學好，這次也算是點小行動，望大伙鼓勵之，別砸我磚頭。

???? AOP != Interception

??? 最近，許多作者在討論AOP(面向方面編程)，但這整個事情是不可置信的強大和精彩。然而，他們中的大部分真正談論的是一種叫做攔截器的設計模式。這些人并不笨，他們也沒有被誤導。雖然攔截器從它本身說來是一種強有力的機制，但是它與AOP是不一樣的。雖然它們享有許多共同的特征，但是將AOP看成是攔截器就像將OOP看成是數據結構和一堆函數指針。就像直到我們將對象看作僅僅是編碼和數據這種觀念拋棄之后才真正懂得對象一樣，如果我們像真正的懂得在AOP中潛在的巨大能量，我們就需要超越將AOP與攔截器看成是相同的東西的思想。它們在某些點上顯然是很有關聯的，他們并不是等價的。
一.定義
?? ?對初學者來說，因為90%的參數是基于語法的差異性，讓我們首先確定一下幾個術語。
??? 1)面向切面編程
??????? ?i)? "面向切面的軟件發展是一種在軟件發展中備受關注的新技術，AOSD報文交換集中技術使得模塊化一個系統的方方面面成為可能。" -AOSD主頁
???? ii) "AOP的主要思想是雖然面向對象程序語言中層級化的模塊化機制已經非常的有用，但是他們天生無

法將復雜系統的所有方面都模塊化。相應地，我們相信""
?? 2)攔截器
?????? ?"攔截器架構模式允許能夠透明的加入到框架中，并能夠在某事件發生的時候自動的觸發"--軟件架構模式。乍一看，這兩個東西出奇的相似，攔截器在一個確定的執行點執行，主要用來在它攔截到一個對象方法時能提供額外的行為，并且形成了在對象的切入點之上通過在源碼中增加聲明式的切入點來添加額外的行為。雖然有如此多的事情，但是，它們的細節真正體現在細節和明顯的層下。但是，作為討論的一部分，為了真正的看到為什么它們交迭了如此多我們再需要定義幾個術語。
?? 1）分離的關注點：一個關注點從本質上來說當我們需要在我們的軟件系統上建立模塊時是一個自動的事情。例如，在一個財會系統中，資產概念就是一個切入點，因此，我們嘗試和捕獲將與資產相關的所有概念變成我們在OO系統中調用的對象時的連貫的事情。這個使得我們更好地跟蹤系統中地提取物，允許我們隨著時間的流逝能更好地維護。每一種程序設計語言含蓄地將這個作為它們的中心目標，即使這些關注點本身和它們應該怎樣地捕獲存在很大的不同。
?? 2）橫切關注點：橫切關注點，像在面向方面的著作中所說的那樣，是系統中的一部分，在標準的對象模型語義學中，它不能通過默認的構造函數捕獲。例如，考慮跟蹤一個方法的入口和出口。通常來說，我們通過類本身來達到這個目標，例如我們可以通過如下方式：
????? if (Debugging.isEnabled())???
????????????? Debugging.trace("Method foo() entered");// . . .
????? if (Debugging.isEnabled())???
????????????? Debugging.trace("Method foo() exiting");
???? 就像我們可以想象的那樣，這種行為捕可以通過基類繼承或者通過提供一個對另一個類的內部引用來實現（OO系統建造一個干凈的分離的關注點的規范化的方式是通過繼承或合成），每一個想要跟蹤的方法都要包含這4行語句。另外，更負責的是，橫向切入點在企業系統中的通用用法包括持久化（這點與舊有的對象關系是不一樣的），同步行為（我們的對象在多線程中應該怎么處理），以及遠程化（當我們的對象允許通過進程邊界進行調用時我們應該怎樣處理）。所列的這些問題在傳統的面向對象環境中都不能清楚地被捕獲。
??
???????? 攔截器和AOP
???????? 攔截器模式來自POSA2,沒有更好地定義出來時，我一直引用規范化定義， 這個問題是"發展容易擴展的框架"，這種解決方案如下：
??????? 允許應用程序通過注冊"頻帶外"的通過預先定義的接口帶有框架的服務對框架進行清晰地擴展，并允許框架在這些事件發生時自動的觸發這些服務（注:在本文種，"事件"指的是應用級別的事件，例如在ORB框架中傳輸請求和回應。這些事件通常只在框架實現中是可見的）。另外，打開框架的實現，以便外面的服務能夠對框架行為的各方面進行進入和控制。
?????? 換句話說，攔截器常隱含的包含如下東西
?????? 1.顯式的支持攔截器系統：POSA2將其叫做框架，COM+,.NET,servlets和EJB在它們的容器邊界做這些事情，但是它們潛在的思想是一樣的--在某些地方，某些種類的構造器是那些提供攔截器行為的構造器，顯然將攔截器調用流作為通用處理的一部分。這就意味著。。。。。。。例如，在servlet框架中（開始于servlet2.3規范），攔截器通過過濾器提供，允許些servlet的人有機會攔截對servlet和jsp（或任意url）的請求和回應。但是，攔截器僅能用于對url請求和呼應進行控制，因此過濾器不能夠做到如下東西，例如：攔截不能調用普通的java類或者通過像RML或其他系統等渠道調用。
????? 2. 請求/回應渠道的概念：攔截器與請求/回應語義學產生了很重要的依賴關系，自從攔截器常常用來在方法的入口和出口完成某些功能，這就意味著很大數量的相互影響是非接觸的或難以獲得的（如果這有點抽象，有賴于--這個可能更易理解）。
????? 3. 攔截器在一個運行時構造器中差不多是普及的：POSA2顯式的指出，這些服務概念的引用在所有的情況下避過那不都是許亞好的，因此攔截器的行為不能靜態的分層化--它必須在運行時注冊。不幸運的是，這也意味著一定數量的運行時超載，特別地，如果攔截器事件模型是粗糙的。例如，在.NET的上下文對象架構中，方法調用既在既在對象外部，又在通過IMessageSink-and-friends架構能夠進行攔截的上下文內部。但是，一旦注冊，上下文攔截器必須在任意方法的進入和進出上下文時被調用；沒有可選的其他方式來指明這個攔截器只對某種類型的方法有效。

???? （未完待續）