Spring AOP理解

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

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

面向切面編程（AOP是Aspect Oriented Program的首字母縮寫） ，咱們知道，面向對象的特色是繼承、多態和封裝。而封裝就要求將功能分散到不一樣的對象中去，這在軟件設計中每每稱爲職責分配。實際上也就是說，讓不一樣的類設計不一樣的方法。這樣代碼就分散到一個個的類中去了。這樣作的好處是下降了代碼的複雜程度，使類可重用。      

可是人們也發現，在分散代碼的同時，也增長了代碼的重複性。什麼意思呢？好比說，咱們在兩個類中，可能都須要在每一個方法中作日誌。按面向對象的設計方法，咱們就必須在兩個類的方法中都加入日誌的內容。也許他們是徹底相同的，但就是由於面向對象的設計讓類與類之間沒法聯繫，而不能將這些重複的代碼統一塊兒來。    

也許有人會說，那好辦啊，咱們能夠將這段代碼寫在一個獨立的類獨立的方法裏，而後再在這兩個類中調用。可是，這樣一來，這兩個類跟咱們上面提到的獨立的類就有耦合了，它的改變會影響這兩個類。那麼，有沒有什麼辦法，能讓咱們在須要的時候，隨意地加入代碼呢？這種在運行時，動態地將代碼切入到類的指定方法、指定位置上的編程思想就是面向切面的編程。       

通常而言，咱們管切入到指定類指定方法的代碼片斷稱爲切面，而切入到哪些類、哪些方法則叫切入點。有了AOP，咱們就能夠把幾個類共有的代碼，抽取到一個切片中，等到須要時再切入對象中去，從而改變其原有的行爲。這樣看來，AOP其實只是OOP的補充而已。OOP從橫向上區分出一個個的類來，而AOP則從縱向上向對象中加入特定的代碼。有了AOP，OOP變得立體了。若是加上時間維度，AOP使OOP由原來的二維變爲三維了，由平面變成立體了。從技術上來講，AOP基本上是經過代理機制實現的。     

 AOP在編程歷史上能夠說是里程碑式的，對OOP編程是一種十分有益的補充。

首先面向切面編程是什麼。就指是把邏輯代碼和處理瑣碎事務的代碼分離開，以便可以分離複雜度。讓人在同一時間只用思考代碼邏輯，或者瑣碎事務。代碼邏輯好比是插入一條數據，那麼瑣碎事務就包括獲取鏈接和關閉鏈接，事務開始，事務提交。切面就是指在大堆繁雜事務中的邏輯代碼。而後舉個例子：先假設你有一段邏輯代碼要寫～ 在這段代碼以前要寫log；代碼完成以後要寫log。結局就是一大堆的log代碼就淹沒了邏輯代碼。aop的想法就是將非邏輯部分的代碼抽離出來，只考慮邏輯代碼就好了，我把框框畫好，這裏寫前面的log，這裏寫邏輯，這裏寫後面的log。事實上用着嘛～ 我沒用過。邏輯代碼好像和非邏輯代碼是分開在不一樣文件的。我的以爲跳文件也很煩躁。感受應該是系統大到某種程度纔會須要這麼嚴格的複雜度控制吧。--------------------------無責任吐槽分割線--------------------------（本故事純屬虛構，若有雷同純屬巧合）雖然我沒用過，可是忽然想到我曾經在某個系統裏見過這貨。這個系統是這樣的，使用了aop，將數據庫的事務管理啊什麼的都搞定了封印了。 可是，這個系統的log語句沒有被封印，邏輯代碼都還被logger.log("xxxxx")這樣的語句給包圍着。 若是說一個函數的話，可能就是有一半在作log，一個類有一半在作log。就算框架給框框畫好了要用aop，也有人有辦法不用，或者用很差。其實不用aop的框架的話，也能夠把前面和後面的瑣碎事務本身抽象一下也能分開，這雖然不用框架可是也有aop的意思，就把瑣碎事務都壓縮到一個前置函數和一個後置函數裏面。

1.我所知道的aop

　　初看aop,上來就是一大堆術語，並且還有個拉風的名字，面向切面編程，都說是OOP的一種有益補充等等。一會兒讓你不知所措，心想着：怪不得不少人都和我說aop多難多難。當我看進去之後，我才發現：它就是一些Java基礎上的樸實無華的應用，包括ioc，包括許許多多這樣的名詞，都是萬變不離其宗而已。

  2.爲何用aop

　　1就是爲了方便，看一個國外頗有名的大師說，編程的人都是「懶人」，由於他把本身作的事情都讓程序作了。用了aop能讓你少寫不少代碼，這點就夠充分了吧

　　2就是爲了更清晰的邏輯，可讓你的業務邏輯去關注本身自己的業務，而不去想一些其餘的事情，這些其餘的事情包括：安全，事物，日誌等。

 3.那些aop的術語

　　初看這麼多術語，一會兒都很差接受，慢慢來，很快就會搞懂。

    1.通知（Advice）

　　就是你想要的功能，也就是上面說的 安全，事物，日誌等。你給先定義好把，而後在想用的地方用一下。

    2.鏈接點（JoinPoint）

　　這個更好解釋了，就是spring容許你使用通知的地方，那可真就多了，基本每一個方法的前，後（二者都有也行），或拋出異常時均可以是鏈接點，spring只支持方法鏈接點.其餘如aspectJ還可讓你在構造器或屬性注入時都行，不過那不是咱關注的，只要記住，和方法有關的前先後後（拋出異常），都是鏈接點。

    3.切入點（Pointcut）

　　上面說的鏈接點的基礎上，來定義切入點，你的一個類裏，有15個方法，那就有幾十個鏈接點了對把，可是你並不想在全部方法附近都使用通知（使用叫織入，之後再說），你只想讓其中的幾個，在調用這幾個方法以前，以後或者拋出異常時乾點什麼，那麼就用切點來定義這幾個方法，讓切點來篩選鏈接點，選中那幾個你想要的方法。

    4.切面（Aspect）

　　切面是通知和切入點的結合。如今發現了吧，沒鏈接點什麼事情，鏈接點就是爲了讓你好理解切點，搞出來的，明白這個概念就好了。通知說明了幹什麼和何時幹（何時經過方法名中的before,after，around等就能知道），而切入點說明了在哪幹（指定究竟是哪一個方法），這就是一個完整的切面定義。

    5.引入（introduction）

　　容許咱們向現有的類添加新方法屬性。這不就是把切面（也就是新方法屬性：通知定義的）用到目標類中嗎

    6.目標（target）

　　引入中所提到的目標類，也就是要被通知的對象，也就是真正的業務邏輯，他能夠在絕不知情的狀況下，被我們織入切面。而本身專一於業務自己的邏輯。

    7.代理(proxy)

　　怎麼實現整套aop機制的，都是經過代理，這個一會給細說。

    8.織入(weaving)

　　把切面應用到目標對象來建立新的代理對象的過程。有3種方式，spring採用的是運行時，爲何是運行時，後面解釋。

　　關鍵就是：切點定義了哪些鏈接點會獲得通知

  4.我所理解的aop原理

　　spring用代理類包裹切面，把他們織入到Spring管理的bean中。也就是說代理類假裝成目標類，它會截取對目標類中方法的調用，讓調用者對目標類的調用都先變成調用假裝類，假裝類中就先執行了切面，再把調用轉發給真正的目標bean。

　　如今能夠本身想想，怎麼搞出來這個假裝類，纔不會被調用者發現（過JVM的檢查，JAVA是強類型檢查，哪裏都要檢查類型）。

　　1.實現和目標類相同的接口，我也實現和你同樣的接口，反正上層都是接口級別的調用，這樣我就假裝成了和目標類同樣的類（實現了同一接口，咱是兄弟了），也就逃過了類型檢查，到java運行期的時候，利用多態的後期綁定（因此spring採用運行時），假裝類（代理類）就變成了接口的真正實現，而他裏面包裹了真實的那個目標類，最後實現具體功能的仍是目標類，只不過假裝類在以前幹了點事情（寫日誌，安全檢查，事物等）。

　　這就比如，一我的讓你辦件事，每次這個時候，你弟弟就會先出來，固然他分不出來了，覺得是你，你這個弟弟雖然辦不了這事，可是他知道你能辦，因此就答應下來了，而且收了點禮物（寫日誌），收完禮物了，給把事給人家辦了啊，因此你弟弟又找你這個哥哥來了，最後把這是辦了的仍是你本身。可是你本身並不知道你弟弟已經收禮物了，你只是專心把這件事情作好。

　　順着這個思路想，要是自己這個類就沒實現一個接口呢，你怎麼假裝我，我就壓根沒有機會讓你搞出這個雙胞胎的弟弟，那麼就用第2種代理方式，建立一個目標類的子類，生個兒子，讓兒子假裝我

　　2.生成子類調用，此次用子類來作爲假裝類，固然這樣也能逃過JVM的強類型檢查，我繼承的嗎，固然查不出來了，子類重寫了目標類的全部方法，固然在這些重寫的方法中，不只實現了目標類的功能，還在這些功能以前，實現了一些其餘的（寫日誌，安全檢查，事物等）。

　　此次的對比就是，兒子先從爸爸那把本事都學會了，全部人都找兒子辦事情，可是兒子每次辦和爸爸一樣的事以前，都要收點小禮物（寫日誌），而後纔去辦真正的事。固然爸爸是不知道兒子這麼幹的了。這裏就有件事情要說，某些本事是爸爸獨有的(final的)，兒子學不了，學不了就辦不了這件事，辦不了這個事情，天然就不能收人家禮了。

　　前一種兄弟模式，spring會使用JDK的java.lang.reflect.Proxy類，它容許Spring動態生成一個新類來實現必要的接口，織入通知，而且把對這些接口的任何調用都轉發到目標類。

　　後一種父子模式，spring使用CGLIB庫生成目標類的一個子類，在建立這個子類的時候，spring織入通知，而且把對這個子類的調用委託到目標類。

　　相比之下，仍是兄弟模式好些，他能更好的實現鬆耦合，尤爲在今天都高喊着面向接口編程的狀況下，父子模式只是在沒有實現接口的時候，也能織入通知，應當作一種例外。

前幾篇博客咱們說了JAVA的代理模式，從靜態代理到動態代理，又到CGLIB代理。從靜態代理到動態代理是一種進步，JDK的動態代理和CGLIB的代理，倒是各有優缺點，在使用過程當中，不是非要決出個勝負，根據不一樣的情景，使用不一樣的代理；也能夠根據狀況，二者結合使用，代碼是咱們寫出來的，咱們纔是創造者，知其然，知其因此然，然可用之。

      1、AOP

       這篇博客，咱們說說java的AOP。之因此接着說AOP 是由於，我認爲代理模式和AOP 本就是一家，AOP是一種很先進的思想，而這種思想的技術支撐是：動態代理。最初，我也沒有發現他們的關係，後來走着走着，就從AOP學回到到動態代理了，發現，原來是AOP的實現機制之一就是有「動態代理」的支持。迴歸正題，咱們先說說什麼是AOP？

      AOP ： Aspect Oriented Programming  面向切面編程。它是爲解耦而生的。

      解耦是程序員編碼開發過程當中一直追求的境界。AOP在這方面給程序員帶來的福音，在對業務類的隔離方面來講，它絕對是作到了解耦，但毫不是完美的解耦，這裏在接下來的博客中再作介紹，這篇博客的主題是理解AOP。AOP的具體思想是：定義一個切面，在切面的縱向定義處理方法，處理完成以後，回到橫向業務流，找一個簡單的業務爲例來講：

       從圖中看出，AOP對咱們的業務的縱向走勢不會形成阻礙做用，因此所面向切面變成是對面向對象編程的一種補充。上圖是簡單的一個AOP橫向邏輯切入業務邏輯縱向邏輯的一個直掛展現，有些人會問？爲何要這樣作?咱們有那麼多的橫切行的必要嗎？如今咱們看看使用AOP能夠幫助咱們避免那些問題？基本算是AOP的一個由來吧。

      先來看第一個問題，aop解決了大量的代碼重複。

      我須要作一個日誌的功能，即須要在每條線上都進行日誌的處理，咱們是否是要這麼寫？

     這樣有不少條線中都包含了一段相同的代碼，你怎麼看？抽出來唄，做爲公共的部分，被調用。

         而後呢，到這裏咱們尚未結束，爲何這麼說？

         這樣每一個方法都和這個公共的功能類有關聯關係，這裏只是咱們的抽出公共代碼，解決了代碼重複。咱們須要作的是「解耦」，將業務類和這個公共的功能類之間的耦合解開，在運行的時候動態的給切入到每一個運行的業務類中，那麼怎麼實現呢？

        AOP實現業務和切入類的解耦。

       AOP是如何實現的呢？藉助動態代理。前幾篇博客咱們說了動態代理，動態代理的一個最大特徵就是能夠延遲對象的加載，即在運行期再肯定調用者和被調用者的關係。AOP也就是利用了動態的這個特徵來實現的解耦。具體我就很少說了，詳情看代碼。

     

       AOP的主要應用

      直接上圖吧。

      

     這張圖也形象的展現了，軟件的縱向業務發展，和軟件的橫向AOP切入的原理。我以爲之後，咱們的開發能夠更多的抽取這樣的切面，讓每一個系統的開發只專一於核心的業務，而不考慮這樣，那樣的共性問題。

AOP(Aspect-Oriented Programming)實際上是OOP(Object-Oriented Programing)思想的補充和完善。咱們知道，OOP引進"抽象"、"封裝"、"繼承"、"多態"等概念,對萬事萬物進行抽象和封裝，來創建一種對象的層次結構，它強調了一種完整事物的自上而下的關係。可是具體細粒度到每一個事物內部的狀況，OOP就顯得無能爲力了。好比日誌功能。日誌代碼每每水平地散佈在全部對象層次當中，卻與它所散佈到的對象的核心功能毫無關係。對於其餘不少相似功能，如事務管理、權限控制等也是如此。這致使了大量代碼的重複，而不利於各個模塊的重用。
   而AOP技術則偏偏相反，它利用一種稱爲"橫切"的技術，可以剖解開封裝的對象內部，並將那些影響了多個類而且與具體業務無關的公共行爲 封裝成一個獨立的模塊（稱爲切面）。更重要的是，它又能以巧奪天功的妙手將這些剖開的切面復原，不留痕跡的融入核心業務邏輯中。這樣，對於往後橫切功能的編輯和重用都可以帶來極大的方便。
AOP技術的具體實現，無非也就是經過動態代理技術或者是在程序編譯期間進行靜態的"織入"方式。下面是這方面技術的幾個基本術語：
一、join point（鏈接點）：是程序執行中的一個精確執行點，例如類中的一個方法。它是一個抽象的概念，在實現AOP時，並不須要去定義一個join point。
二、point cut（切入點）：本質上是一個捕獲鏈接點的結構。在AOP中，能夠定義一個point cut，來捕獲相關方法的調用。
三、advice（通知）：是point cut的執行代碼，是執行「方面」的具體邏輯。
四、aspect（方面）：point cut和advice結合起來就是aspect，它相似於OOP中定義的一個類，但它表明的更可能是對象間橫向的關係。
五、introduce（引入）：爲對象引入附加的方法或屬性，從而達到修改對象結構的目的。有的AOP工具又將其稱爲mixin。

全部AOP技術基本上都是基於以上這些概念實現的。