雜項-編程：AOP（面向切面編程）

ylbtech-雜項-編程：AOP（面向切面編程）

在軟件業，AOP爲Aspect Oriented Programming的縮寫，意爲： 面向切面編程， 經過預編譯方式和運行期動態代理實現程序功能的統一維護的一種技術。AOP是 OOP的延續，是軟件開發中的一個熱點，也是 Spring框架中的一個重要內容，是 函數式編程的一種衍生範型。 利用AOP能夠對業務邏輯的各個部分進行隔離，從而使得業務邏輯各部分之間的耦合度下降，提升程序的可重用性，同時提升了開發的效率。

1.返回頂部

一、

名稱含義

Aspect Oriented Programming（AOP）是較爲熱門的一個話題。AOP，國內大體譯做「 面向切面編程」。

「面向切面編程」,這樣的名字並非很是容易理解，且容易產生一些誤導。有些人認爲「OOP/OOD11即將落伍， AOP是新一代軟件開發方式」。顯然，發言者並無理解AOP的含義。Aspect，的確是「方面」的意思。不過，漢語傳統語義中的「方面」，大多數狀況下指的是一件事情的不一樣維度、或者說不一樣角度上的特性，好比咱們常說：「這件事情要從幾個方面來看待」，每每意思是：須要從不一樣的角度來看待同一個事物。這裏的「方面」，指的是事物的外在特性在不一樣觀察角度下的體現。而在AOP中，Aspect的含義，可能更多的理解爲「切面」比較合適。

能夠經過預編譯方式和運行期動態代理實如今不修改源代碼的狀況下給程序動態統一添加功能的一種技術。AOP實際是GoF設計模式的延續，設計模式孜孜不倦追求的是 調用者和被調用者之間的解耦,提升代碼的靈活性和可擴展性，AOP能夠說也是這種目標的一種實現。

在Spring中提供了面向切面編程的豐富支持，容許經過分離應用的業務邏輯與系統級服務（例如審計（auditing）和 事務（transaction）管理）進行 內聚性的開發。 應用對象只實現它們應該作的——完成業務邏輯——僅此而已。它們並不負責（甚至是意識）其它的系統級關注點，例如 日誌或事務支持。

 

主要功能

日誌記錄，性能統計，安全控制，事務處理， 異常處理等等。

 

主要意圖

將日誌記錄，性能統計，安全控制，事務處理， 異常處理等代碼從業務邏輯代碼中劃分出來，經過對這些行爲的分離，咱們但願能夠將它們獨立到非指導業務邏輯的方法中，進而改變這些行爲的時候不影響業務邏輯的代碼。

 

AOP/OOP

區分

AOP、OOP在字面上雖然很是相似，但倒是面向不一樣領域的兩種設計思想。OOP（ 面向對象編程） 針對業務處理過程的實體及其屬性和行爲進行抽象封裝，以得到更加清晰高效的 邏輯單元劃分。

而AOP則是針對業務處理過程當中的切面進行提取，它所面對的是處理過程當中的某個步驟或階段，以得到邏輯過程當中各部分之間低 耦合性的隔離效果。這兩種設計思想在目標上有着本質的差別。

上面的陳述可能過於理論化，舉個簡單的例子，對於「僱員」這樣一個 業務實體進行封裝，天然是OOP/OOD的任務，咱們能夠爲其創建一個「Employee」類，並將「僱員」相關的屬性和行爲封裝其中。而用AOP設計思想對「僱員」進行封裝將無從談起。

一樣，對於「權限檢查」這一動做片段進行劃分，則是AOP的目標領域。而經過OOD/OOP對一個動做進行封裝，則有點不三不四。

換而言之，OOD/OOP面向名詞領域，AOP面向動詞領域。

 

關係

不少人在初次接觸 AOP 的時候可能會說，AOP 能作到的，一個定義良好的 OOP 的接口也同樣可以作到，我想這個觀點是值得商榷的。AOP和定義良好的 OOP 的接口能夠說都是用來解決而且實現需求中的橫切問題的方法。可是對於 OOP 中的接口來講，它仍然須要咱們在相應的模塊中去調用該接口中相關的方法，這是 OOP 所沒法避免的，而且一旦接口不得不進行修改的時候，全部事情會變得一團糟；AOP 則不會這樣，你只須要修改相應的 Aspect，再從新編織（weave）便可。 固然，AOP 也絕對不會代替 OOP。核心的需求仍然會由 OOP 來加以實現，而 AOP 將會和 OOP 整合起來，以此之長，補彼之短。

 

應用舉例

假設在一個應用系統中，有一個共享的數據必須被併發同時訪問，首先，將這個 數據封裝在 數據對象中，稱爲Data Class，同時，將有多個訪問類，專門用於在同一時刻訪問這同一個數據對象。

爲了完成上述併發訪問同一資源的功能，須要引入鎖Lock的概念，也就是說，某個時刻，當有一個訪問類訪問這個數據對象時，這個數據對象必須上鎖Locked，用完後就當即解鎖unLocked，再供其它訪問類訪問。

使用傳統的編程習慣，咱們會建立一個 抽象類，全部的訪問類繼承這個抽象父類，以下：

abstract class Worker {
    abstract void locked();
    abstract void accessDataObject();
    abstract void unlocked();
}

accessDataObject()方法須要有「鎖」狀態之類的相關代碼。

Java只提供了單繼承，所以具體訪問類只能繼承這個父類，若是具體訪問類還要繼承其它父類，好比另一個如Worker的父類，將沒法方便實現。

重用被打折扣，具體訪問類由於也包含「鎖」狀態之類的相關代碼，只能被重用在相關有「鎖」的場合，重用範圍很窄。

仔細研究這個應用的「鎖」，它其實有下列特性：

「鎖」功能不是具體訪問類的首要或主要功能，訪問類主要功能是訪問數據對象，例如讀取數據或更改動做。

「鎖」

「鎖」功能實際上是這個系統的一個縱向切面，涉及許多類、許多類的方法。如右圖：

 

所以，一個新的程序結構應該是關注系統的縱向切面，例如這個應用的「鎖」功能，這個新的程序結構就是aspect（方面）

在這個應用中，「鎖」方面（aspect）應該有如下職責：

提供一些必備的功能，對被訪問對象實現加鎖或解鎖功能。以保證全部在修改 數據對象的操做以前可以調用lock()加鎖，在它使用完成後，調用unlock()解鎖。

 

應用範圍

很明顯， AOP很是適合開發J2EE容器服務器，JBoss 4.0正是使用AOP框架進行開發。

具體功能以下：

Authentication 權限

Caching 緩存

Context passing 內容傳遞

Error handling  錯誤處理

Lazy loading 延時加載

Debugging 調試

logging, tracing, profiling and monitoring 記錄跟蹤 優化 校準

Performance optimization性能優化

Persistence 持久化

Resource pooling 資源池

Synchronization 同步

Transactions 事務

【AOP有必要嗎？】

固然，上述應用範例在沒有使用AOP狀況下，也獲得瞭解決，例如JBoss 3.XXX也提供了上述應用功能，而且沒有使用AOP。

可是，使用AOP可讓咱們從一個更高的抽象概念來理解軟件系統，AOP也許提供一種有價值的工具。能夠這麼說：由於使用AOP結構，JBoss 4.0的源碼要比JBoss 3.X容易理解多了，這對於一個大型複雜系統來講是很是重要的。

從另一個方面說，好像不是全部的人都須要關心AOP，它多是一種架構設計的選擇，若是選擇J2EE系統，AOP關注的上述通用方面都已經被J2EE容器實現了，J2EE應用系統開發者可能須要更多地關注行業應用方面aspect。

傳統的程序一般表現出一些不能天然地適合單一的 程序模塊或者是幾個緊密相關的程序模塊的行爲，AOP 將這種行爲稱爲橫切，它們跨越了給定編程模型中的典型職責界限。橫切行爲的實現都是分散的， 軟件設計師會發現這種行爲難以用正常的邏輯來思考、實現和更改。最多見的一些橫切行爲以下面這些：

日誌記錄，跟蹤，優化和監控

事務的處理

持久化

性能的優化

資源池，如 數據庫鏈接池的管理

系通通一的認證、權限管理等

應用系統的異常捕捉及處理

針對具體行業應用的橫切行爲

前面幾種橫切行爲都已經獲得了密切的關注，也出現了各類有價值的應用，但也許從此幾年，AOP 對針對具體行業應用的貢獻會成爲使人關注的焦點。

 

實現項目

AOP是一個概念，並無設定具體語言的實現，它能克服那些只有單繼承特性語言的缺點（如Java），AOP具體實現有如下幾個項目：

AspectJ (TM)： 建立於Xerox PARC. 有近十年曆史，成熟

缺點：過於複雜；破壞封裝；須要專門的Java 編譯器。

動態AOP：使用JDK的動態代理API或 字節碼Bytecode處理技術。

基於動態代理API的具體項目有：

JBoss 4.0 JBoss 4.0服務器

基於字節碼的項目有：

aspectwerkz ，spring

 

做用

面向過程編程離咱們已經有些遙遠， 面向對象編程正主宰着軟件世界。當每一個新的 軟件設計師都被要求掌握如何將需求功能轉化成一個個類，而且定義它們的 數據成員、行爲，以及它們之間複雜的關係的時候，面向切面編程（Aspect-Oriented Programming，AOP）爲咱們帶來了新的想法、新的思想、新的模式。

若是說面向對象編程是關注將需求功能劃分爲不一樣的而且相對獨立，封裝良好的類，並讓它們有着屬於本身的行爲，依靠繼承和 多態等來定義彼此的關係的話；那麼面向切面編程則是但願可以將通用需求功能從不相關的類當中分離出來，可以使得不少類共享一個行爲，一旦發生變化，沒必要修改不少類，而只須要修改這個行爲便可。

面向切面編程是一個使人興奮不已的新模式。就開發軟件系統而言，它的影響力必將會和有着數十年應用歷史的 面向對象編程同樣巨大。 面向切面編程和麪向對象編程不但不是互相競爭的技術並且彼此仍是很好的互補。面向對象編程主要用於爲同一對象層次的公用 行爲建模。它的弱點是將公共行爲應用於多個無關對象模型之間。而這偏偏是面向切面編程適合的地方。有了 AOP，咱們能夠定義交叉的關係，並將這些關係應用於跨模塊的、彼此不一樣的對象模型。AOP 同時還可讓咱們層次化功能性而不是嵌入功能性，從而使得代碼有更好的可讀性和易於維護。它會和麪向對象編程合做得很好。

 

實現

AOP 是一個概念，一個規範，自己並無設定具體語言的實現，這實際上提供了很是廣闊的發展的空間。AspectJ是AOP的一個很悠久的實現，它可以和 Java 配合起來使用。

介紹 AspectJ 的使用和編碼不是本文的目的，你能夠在 Google 上找到不少有關它的材料。

這裏只是重溫 AspectJ 中幾個必需要了解的概念：

Aspect： Aspect 聲明相似於 Java 中的類聲明，在 Aspect 中會包含着一些 Pointcut 以及相應的 Advice。

Joint point：表示在程序中明肯定義的點，典型的包括方法調用，對類成員的訪問以及 異常處理程序塊的執行等等，它自身還能夠嵌套其它 joint point。

Pointcut：表示一組 joint point，這些 joint point 或是經過邏輯關係組合起來，或是經過通配、 正則表達式等方式集中起來，它定義了相應的 Advice 將要發生的地方。

Advice：Advice 定義了在 pointcut 裏面定義的程序點具體要作的操做，它經過 before、after 和 around 來區別是在每一個 joint point 以前、以後仍是代替執行的代碼。

下面要討論的這些問題，也許正是接觸了 AOP 以後所困惑的。

AOP 幫助咱們解決了新的問題沒有？

AOP 並無幫助咱們解決任何新的問題，它只是提供了一種更好的辦法，可以用更少的工做量來解決現有的一些問題，而且使得系統更加健壯，可維護性更好。同時，它讓咱們在進行系統架構和 模塊設計的時候多了新的選擇和新的思路。

 

 

工業化應用

這個問題很難回答，其實最好的答案就是嘗試，用成功的項目或是產品來回答。Jboss 4.0 就是徹底採用 AOP 的思想來設計的 EJB 容器，它已經經過了 J2EE 的認證，而且在工業化應用中證實是一個優秀的產品。相信在不遠的未來，會出現更多采用 AOP 思想設計的產品和行業應用。

 

 

小結

AOP 正向咱們走來，咱們須要關注的是怎麼樣使得它可以爲咱們的軟件系統的設計和實現帶來幫助。本文旨在給你們一點啓發，可以在更多的領域更深刻的應用 AOP 的思想。

二、

2.返回頂部

 

3.返回頂部

 

4.返回頂部

 

5.返回頂部

一、

https://baike.baidu.com/item/AOP/1332219

二、

 

6.返回頂部

 

做者：ylbtech 出處：http://ylbtech.cnblogs.com/ 本文版權歸做者和博客園共有，歡迎轉載，但未經做者贊成必須保留此段聲明，且在文章頁面明顯位置給出原文鏈接，不然保留追究法律責任的權利。