什么是AOP？

最初聽到AOP這個名詞，我總是錯覺其與OOP是否具有孿生性？那么，所謂AOP，即面向方面編程（Aspect Oriented Programming），是否是面向對象編程的一種進化呢？關鍵就在于我們對“方面（Aspect）”的理解。確實，“方面”這個詞語是夠抽象的，簡單地說，它就是將那些與業務無關，卻為業務模塊所共同調用的邏輯或責任，例如事務處理、日志管理、權限控制等，封裝起來，便于減少系統的重復代碼，降低模塊間的耦合度，并有利于未來的可操作性和可維護性。

對于OOP，Bruce Eckel有一句名言，“Everything is Object.”確實，在程序的世界里，我們可以將萬事萬物定義為一種對象，并將這些對象的行為和屬性封裝起來，同時定義好對象與對象之間的關系。很顯然，對于AOP而言，我們無法套用這句名言，妄言“Everything is Aspect.”實質上，AOP只是OOP的一種補充或某種改進，它轉換了編程的范式和視角，關注了一直以來被OOP忽 略或者說未能解決好的角落，使開發人員可以更好地將本不該彼此糾纏在一起的責任（如銀行業務和事務處理）分離開來。通過面向方面的編程，可以將程序的責任 分開，對象與方面互不干擾。面向方面的模塊并非顯式地為對象所調用，而是通過或注入或截取的方式，去獲得被封裝的對象內部方法間的消息，然后做出相應地處 理。也許面向方面的模式破壞了對象的封裝，卻正其如此，方才能降低模塊與模塊之間的耦合度。同樣地，通過對“方面”的封裝，將這些通用的功能從不同的類中 分離出來，使不同的模塊都能共享同樣的“方面”，這也極大地減少了重復代碼。

如果說“對象”是一個空心的圓柱體，其中封裝的是對象的屬性和行為；那么面向方面編程的方法，就仿佛一把利刃，將這些空心圓柱體剖開，以獲得其內部的消息。而剖開的切面，也就是所謂的“方面”了。然后它又以巧奪天功的妙手將這些剖開的切面復原，不留痕跡。

?

AOP，并不具有革命的驅動力

?

個人認為，AOP還談不上是一種編程的思想，只能說是一種方法而已。溯其根源，一般認為，面向方面編程（AOP）是施樂公司帕洛阿爾托研究中心（Xerox PARC）在上世紀90年代發明的一種編程范式。它在OOP的縫隙之中，抽象出“方面”的概念，目的就是為了打破對象的封裝性，以“方面”的方式對原有的模塊進行重組，抽取那些與業務無關卻為整個系統所通用的功能，最終封裝在一起。

那么，最終封裝好的這些所謂“方面”，如何被業務對象所調用呢？這就需要“方面”擁有截取封裝對象消息的能力。在JAVA世界里，AOP的應用已經走向比較成熟的應用。AspectJ、Spring，在體現AOP能力上來說，已經漸趨成熟。甚至在JBOSS4.0中，已經引入了AOP框架進行開發，并在權限管理（Authentication）、錯誤處理（Error Handling）、事務處理（Transactions）、持久化（Persistence）等方面取得了很好的應用。在.Net平臺下，對于AOP的應用似乎卻走到了后面。在Microsoft 推出的.Net Framework 1.1中，并沒有應用AOP，也未曾提供AOP的框架。不過.Net Framework仍然提供了實現AOP的技術可能，即通過.Net Framework的反射機制或.Net Remoting的代理機制獲取元數據信息或對象內部間傳遞的消息。同時，我也看到開源社區中的AOP.Net項目，采用了非托管的.Net Profilling API，它采用了非托管的C++ COM組件，可以在相關事件發生時，通過.Net系統捕獲其消息并發送通知。

AOP在企業應用中正逐漸體現其自身的價值。但正如其名，它的作用更多地是關注于系統的某一方面。AOP還缺乏革命的驅動力，并不足以顛覆OOP世界。我們不可能預見AOP之于OOP，象當初面向對象編程取代面向過程編程那樣，具有強大至可以顛覆程序員思想的力量。而事實上，AOP從一誕生以來，就從未貼上“革命”的標簽。相反，它更多地起到了推波助瀾的作用，彌補著OOP的缺失，進而在OO程序設計中，擴展了一種更寬廣的模式。

?

AOP，“設計模式”的延續

?

不錯，AOP的目的，恰恰就是做了“設計模式”想做卻一直未曾做到的功能。GOF的“設 計模式”給了我們設計的典范與準則，通過最大程度的利用面向對象的特性，諸如利用繼承、多態，對責任進行分離、對依賴進行倒置，面向抽象，面向接口，最終 設計出靈活、可擴展、可重用的類庫、組件，乃至于整個系統的架構。在設計的過程中，通過各種模式體現了對象的行為，暴露的接口，對象間關系，以及對象分別 在不同層次中表現出來的形態。然而鑒于對象封裝的特殊性，“設計模式”的觸角始終在接口與抽象中大做文章，而對于對象內部則無能為力。

舉例來說，我們需要為系統提供日志的能力。雖然我們可以通過裝飾模式（Decorate Pattern），提供各種日志的組合，但不可避免的是，大量的日志對象實例代碼的存在，導致了重復代碼的壞味道，同時也導致了強依賴性，這并不利于模塊間的解耦。如果我們通過AOP， 將這些日志的功能看作是一個“方面”，然后將系統中需要日志能力的模塊置于該“方面”的偵聽之中，抽象出來的“方面”好像是一個容器，在其內部的世界里， 不分貧富貴賤。只要執行了某種業務，這個容器就會忠實地記錄這些模塊間傳遞的消息。至于這些模塊到底實現了何種業務，卻并非“方面”所關注的。

前面已經敘述到，面向方面編程的價值主要體現在事務處理、日志管理、權限控制等與業務無關，卻為業務模塊所共同調用的邏輯或責任上，而這些所謂的“方面”，恰恰是企業應用時非常必須的。因此，與其說AOP是一種編程的技術，毋寧說AOP是一種企業的“設計模式”。它彌補了OOP之拙，卻未曾也不可能超越OOP而單獨存在。

轉載于:https://www.cnblogs.com/EricGu/articles/1010599.html

總結

以上是生活随笔為你收集整理的关于AOP的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。