切面范式
橫看成嶺側成峰 ——《蘇轼·題西林壁》
引號重開話題：“OOP方興未艾，AOP又開始嶄露頭角。AOP算是OOP的一種分支、一種補充還是一種超越？”
歎號故作捶胸頓足狀：“OOP還沒有完全吃透，又來了個什麼AOP。”
“不同的人對新生事物采取不同的態度。”冒號王顧左右而言他，“追星族傾向於盲目追捧，唯恐落伍，他們信奉新潮的流行的就是好的；守舊派傾向於本能抗拒，回避求新，他們認為經典的傳統的才是好的。”
引號和歎號互視一眼，不情願地戴上了老冒派發的帽子。
冒號續道：“從宏觀角度看，太陽底下沒有新鮮事——AOP無非是SoC原理和DRY原則的一種應用；從微觀角度看，太陽每天都是新的——AOP雖自OOP的土壤中長出，卻脫離藩籬自成一體，並且嫁接到非OOP的領地，不僅在純過程式語言、函數式語言、甚至邏輯式語言中得到發展，而且本身也具備了一定的聲明式語言特征，成為一種新的軟件模塊化方式。”
問號舉手：“什麼是SoC和DRY？”
引號代答：“SoC就是Separation of concerns，即關注點分離；DRY是Don’t Repeat Yourself，即盡量減少重復代碼。”
“答案正確，加十分！”冒號戲贊道，“不良代碼通常有兩種病征：一是紛亂如麻，糾纏打結，可謂剪不斷理還亂；二是疊床架屋，臃腫不堪。治療此類病症一個有效的方法是抽象與分解：從問題中抽象出一些關注點，再以此為基礎進行分解。分解後的子問題主題鮮明並且獨立，不會牽一發而動全身。同時具有相同特征的部分可以象代數中的公因子一樣提取出來，減少了代碼重復。”
句號醒悟道：“這不就是模塊化嗎？”
“准確地說，抽象是前提，分解是方式，模塊化是結果。”冒號很講究精確，“大家記得庖丁解牛的故事吧？在常人眼中復雜的牛體，庖丁經過抽象，已目無全牛，及至提刀分解，自是游刃有余。待牛如土委地，模塊化既成。”
句號舉一反三：“前面提到的編程范式的基本思想大多不也如此？將程序分別抽象分解為過程、函數、斷言、對象和進程，就依次成為過程式、函數式、邏輯式、對象式和並發式。至於泛型式——”
句號講不下去了。
“泛型式雖未引入新類型的模塊，其核心也是抽象出算法後與數據分解。”冒號為其解圍，“以此類推，切面式的AOP將程序抽象分解為切面。”
問號提問：“抽象與分解的原則是什麼？”
冒號作了個V字：“兩條：單一化，正交化。每個模塊職責明確專一，模塊之間相互獨立，即高聚合低耦合（high cohesion & low coupling）。此原則相當普適，是分析復雜事物的一種基本方法，在數學和物理中應用得尤為廣泛，如質因式分解、正交分解、譜分解等等。”
逗號調皮地抬槓：“為什麼稱為正交化呢？斜交化不行嗎？”
冒號呵呵一笑：“互為正交的兩個向量在彼此方向上投影為零，意味著彼此獨立，互不影響，斜交可不行。”
逗號吐了吐舌頭。
“誠如前述，AOP以切面為模塊。”冒號返回主題，“切面Aspect常直譯為‘方面’，但它描述的是橫切關注點（Cross-cutting concerns），故‘切面’更准確生動，而‘方面’則失之空泛呆板。何謂橫切關注點？顧名思義，乃是與程序的縱向主流執行方向橫向正交的關注焦點。不妨回顧一下，無論是過程式的函數，還是對象式的方法，都包含了完整的執行代碼。但有些代碼橫跨多個模塊，以片斷的形式散落在各處，雖具有相似的邏輯，卻無法用傳統的方式提煉成模塊，難以實現SoC與DRY。典型的例子如：在調用某些對象的方法、讀寫某些對象的域、拋出某些異常等等前後，需要用到統一的業務邏輯，諸如日志輸出、代碼跟蹤、性能監控、異常處理、安全檢查、事務管理等等。為解決此類問題，AOP應運而生。它將每類橫切關注點封裝到單獨的Aspect模塊中，將程序中的一些執行點與相應的代碼綁定起來。單個的執行點稱為接入點（join point），例如：調用某個對象的方法前後；符合預先指定條件的接入點集合稱為切入點（pointcut），例如：所有以set為命名開頭的方法；每段綁定的代碼稱為一個建議（advice）。”
問號有點疑問：“接入點與切入點有何區別？”
冒號釋疑：“望文生義，接入處是點，切入處是面，面由點組成。advice定義於切入點上，執行於接入點處。換言之，共享一段代碼的接入點組成了一個切入點。切入點一般用條件表達式來描述，不僅有廣泛性，還有預見性——以後新增的代碼如果含有滿足切入點條件的接入點，advice中的代碼便自動附著其上。這是AOP的威力所在，但有時也是麻煩所在。”
引號很較真：“好像一些書上把join point譯作連接點，把advice譯作通知。”
“誤導，完全是誤導！”冒號有些痛心疾首，“何謂join point？是advice中額外代碼接入之處，join顯為‘參加’、‘加入’之意。如果說翻作‘連接’只是因缺乏動感和方向性而不夠貼切的話，將advice譯作‘通知’則近乎荒謬了。advice是在原有程序流程中加入的額外流程，可理解為建議采取的措施，而‘通知’強調的是一種信息，難道是程序運行到join point的信息？抑或采取某種行動的信息？簡直不知所雲。”
頓了一會，冒號仍意猶未盡：“英文好的技術不好，技術好的英文不好，兩者都好的不屑去翻譯，導致市面上的譯書雖汗牛充棟，然佳作寥寥。這裡奉勸各位，如果真想成為優秀的程序員，一定要盡可能地讀原文的書籍、文章和文檔。事實上，凡是科學和藝術方面的專業人員，要想專業水平上一層台階，都應讀該專業權威經典的原文。要知道，語言之間的天塹原本難以彌合，譯者的專業水准、語言功底和嚴謹程度更是參差不齊。”
逗號抱怨：“英文雖讀得懂，但太慢、太費勁了。”
“多讀，讀多了就習慣了。”冒號鼓勵著，“對程序員來說，英語也是一門計算機語言。”
問號的求知欲很強：“AOP實現的機理是什麼？”
冒號回答：“如果一個程序是一個管道系統，AOP就是在管道上鑽一些孔，在每個孔中注入新的代碼流。因此AOP實現的關鍵是將advice的代碼嵌入到主體程序之中，術語稱編織（weaving）。這是很自然的——將問題分解之後再合成，問題才得以還原。編織可分兩種：一種是靜態編織，通過修改源碼或字節碼（bytecode）在編譯期（compile-time）前後或加載期（load-time）嵌入代碼；另一種是動態編織，通過代理（proxy）等技術在運行期（run-time）實現嵌入。具體的工具包括一些擴展性語言如AspectJ、AspectC++等和一些framework如AspectWerkz、Spring、Jboss AOP等。”
歎號搔著頭：“聽起來挺復雜的。”
句號說：“這些機理是AOP的實現者需要操心的，使用者只需關心AOP是否好用，性能如何等等。”
冒號表示贊同：“與OOP一樣，AOP在帶來便利的同時，也增加了一定的復雜度和性能損耗。它們更適用於大中型程序，用在小型程序中則不啻牛刀殺雞。”
