前一篇文章呢對 JDK 的動態代理說了一番，也花了不少時間來寫那邊文章。有時候覺得心裏的想法要靠筆桿子（鍵盤）來表達出來，至少說精確表達還是有一定難得的。也許這就是草根階層的筆民與作家之間的差距吧。 OK ， Whatever 感慨少發。切入正題 :AOP.
有時候我懷疑自己到底是個完美主義者還是個做事慢性子的人，總覺得做什麼之前得想好了。先做什麼在做什麼。比如講 AOP 吧，估計兩篇文章下來都沒正經的說給大家寫了個 Spring 框架下的小例子，搞幾行代碼怎麼的。可回頭想想，代碼 - 網上一大堆 ; 例子 — 參考書寫的比我周全。我還不如講點 WHY 少點 HOW 就跟打球一樣基本功好了，什麼動作都好做。基本功不行，運球過半場都成問題。
先從 AOP 的概念說起吧，我們不再去看 Spring-framework 的參考手冊。那些太專業，人家限於篇幅都是以最精闢最簡短的詞語來寫，目的達到了，可問題來了真正有幾個人能把 Cross cutting concern Aspect 等等概念說的大衆化，普通話。讓沒接觸過 Spring 不知道 Spring 爲何物的 JAVA 初學者們一目瞭然呢？
我們平常所接觸的 OOP 都是一個縱向的編程理念，從上往下先做什麼後做什麼。比如你上網購物，你得先登錄然後你在購買，這是一個流程。假如登錄時需要安全性檢查、事務、記錄日誌等，（其實這些都不屬於我們的業務邏輯）。所以我們就不該把這些不屬於業務邏輯的代碼散佈在業務邏輯類之中。此時我們添加一個橫向的編程。等業務邏輯到這一步我們就通過橫向方法實現（也是面向切面的實現）。你所需要實現的橫向功能（或者說需求吧）就是所謂的 cross cutting concern （橫切關注點這個概念比較抽象，誰給大家細說說參考手冊中對這個也是很模糊一帶而過）。
而 Aspect 就是將 cross cutting concern 模塊化，抽取出來形成的一個具體的類。之前你肯能需要在每一個需要進行安全性檢查的類中都去自己實現檢查，而現在不同。 AOP 將它模塊化，所有的安全性檢查都交給 Aspect 來做，你的類中就只管實現自己所需要的業務邏輯了從而你的代碼清晰，功能明確！有人可能要問了，那我自己寫的類怎麼調用這些安全性檢查呢？答案是： Spring 會幫你實現（不然還那麼麻煩用什麼框架呢）。想起代理了嗎？（我在前一篇文章《從 JDK 動態代理說 Spring 的 AOP 》說的比較詳細，可以去看看）。
需要的功能我們抽取出來了 ( 就是說得到切面 Aspect 了 ) ，之後就得去設計具體的方法了（比如需要驗證，那我們就寫一個驗證方法唄）。此時 Advice 就應運而生了，我們在具體的 Aspect 類中去設計具體的方法（也是設計 Advice ，現在應該明白 Advice 的大概了吧其實它就是一個方法。只是 Spring 給它取名曰：通知）。比如我要寫一個用驗證的安全類 Security （負責所有的驗證功能） , 當中有個方法叫 checkSecurity(), 在調用其他方法之前調用它那它就成了前置通知（ before 的概念有了嗎？），之後調用就是後置通知（ after ）異常時調用就成（ Throws 通知）。等等 ..
通知設計完之後我們需要調用啊，可是不是所有的方法都需要這一方法（如果不管三七二十一所有方法通過這橫切面就需要調用，那效率何在？這不比收費站，你過就得給錢啊。呵呵 有車的朋友應該感受比較深刻），這時就需要進行判斷了。判斷的依據就是 Pointcut ，比如我只需要對方法名稱開頭爲 add 的方法調用，那此時的 Pointcut 或許就定義爲 add* 了。這下該明白什麼是 PC 了吧，他就是一套表達式，常用的就支持正則表達式 通過他來進行方法的篩選，類似過濾器。
通知我們設計好了，也進行了篩選了現在就是將刷選的通添加到我的 Target Object 了（這一步 Spring 是通過代理實現的）。這個添加的過程就是所謂的 Weave ， Spring 給了個很酷的名字“織入”。而 TO （目標對象）就是需要調用通知的那個類（暫且說類吧，形象點），而 TO 中那個可以觸發通知的方法就是所謂的 JoinPoint 。
爲了形象話，我把這一些概念組合起來畫了個簡單的示意圖對照那個看文章會更加容易理解的。（JAVAEYE好像不讓傳本地圖片上來，我就在附件裏吧。就是麻煩點了）
說了這麼多，其實要真正理解 AOP 還是那兩個關鍵字眼：代理（ Proxy ） . 這個明白了，那就是你熟練與否的問題了。而熟練就是你花時間多少的問題了。
