在傳統的編寫業務邏輯處理程式碼時，我們通常會習慣性地做幾件事：日誌記錄、交易控制及權限控制等，然後才是編寫核心的業務邏輯處理程式碼。當程式碼寫完成回頭再看時，不禁發現，揚揚灑灑上百行程式碼中，真正用於核心業務邏輯處理才那麼幾行，如圖6-4所示。方法複方法，類複類，就這樣子帶著無可奈何遺憾地度過了多少個春秋。這倒也罷，倘若到了專案的尾聲，突然決定在權限控制上需要進行大的變動時，成千上萬個方法又得一一"登門拜訪"，痛苦"雪上加霜"。
如果能把圖6-4中眾多方法中的所有共有代碼全部抽取出來，放置到某個地方集中管理，然後在具體運行時，再由容器動態織入這些共有代碼的話，最起碼可以解決兩個問題：
Java EE程式設計師在編寫特定的業務邏輯處理方法時，只需關心核心的業務邏輯處理，既提高了工作效率，又使程式碼變更簡潔優雅。
在日後的維護中由於業務邏輯代碼與共有代碼分開存放，而且共有代碼是集中存放的，因此使維護工作變得簡單輕鬆。
面向切面程式設計AOP技術就是為解決這個問題而誕生的，切面就是橫切面，如圖6-5所示，代表的是一個普遍存在的共有功能，例如，日誌切面、權限切面及事務切面等。
以下我們以使用者管理業務邏輯元件UserService的AOP實作過程（見圖6-6）為例，深度剖析一下AOP技術的實作原理。 AOP技術是建立在Java語言的反射機制與動態代理機制之上的。業務邏輯元件在運行過程中，AOP容器會動態建立一個代理物件供使用者調用，該代理物件已經按Java EE程式設計師的意圖將切面成功切入到目標方法的連接點上，從而使切面的功能與業務邏輯的功能同時得以執行。從原理上講，呼叫者直接呼叫的其實是AOP容器動態產生的代理對象，再由代理對象呼叫目標對象完成原始的業務邏輯處理，而代理對象則已經將切面與業務邏輯方法進行了合成。
現將圖6-6所涉及的一些概念解釋如下。
切面（Aspect）：其實就是共有功能的實作。如日誌切面、權限切面、事務切面等。在實際應用中通常是存放共有功能實現的普通Java類，之所以能被AOP容器識別成切面，是在配置中指定的。
通知（Advice）：是切面的具體實現。以目標方法為參考點，根據放置的地方不同，可分為前置通知（Before）、後置通知（AfterReturning）、異常通知（AfterThrowing）、最終通知（After）與環繞通知（Around）5種。在實際應用中通常是切面類別中的一個方法，具體屬於哪一類通知，同樣是在配置中指定的。
連接點（Joinpoint）：就是程式在運作過程中能夠插入切面的地點。例如，方法呼叫、異常拋出或欄位修改等，但Spring只支援方法級的連接點。
切入點（Pointcut）：用來定義通知應該切入到哪些連接點。不同的通知通常需要切入到不同的連接點上，這種精準的匹配是由切入點的正規表示式來定義的。
目標對象（Target）：就是那些即將切入切面的對象，也就是那些被通知的對象。這些物件中已經只剩下乾乾淨淨的核心業務邏輯程式碼了，所有的共有功能程式碼等待AOP容器的切入。
代理物件（Proxy）：將通知套用到目標物件之後被動態建立的物件。可以簡單地理解為，代理物件的功能等於目標物件的核心業務邏輯功能加上共有功能。代理物件對於使用者而言是透明的，是程式運作過程中的產物。
織入（Weaving）：將切面應用到目標物件從而創建一個新的代理物件的過程。這個過程可以發生在編譯期、類別裝載期及運作期，當然不同的發生點有著不同的前提條件。譬如發生在編譯期的話，就要求有一個支持這種AOP實現的特殊編譯器；發生在類裝載期，就要求有一個支持AOP實現的特殊類裝載器；只有發生在運行期，則可直接通過Java語言的反射機制與動態代理機制來動態實作。
以下是補充：
AOP為Aspect Oriented Programming的縮寫，意為：面向切面編程，透過預編譯方式和運行期動態代理實現程序功能的統一維護的一種技術。
AOP與OOP是面向不同領域的兩種設計思想。
OOP（物件導向程式設計）針對業務處理過程的實體及其屬性和行為進行抽象封裝，以獲得更清晰高效的邏輯單元劃分。
AOP則是針對業務處理過程中的切面進行提取，它所面對的是處理過程中的某個步驟或階段，以獲得邏輯過程中各部分之間低耦合性的隔離效果。
我們可以單單從上面的字面上來理解AOP和OOP的話，用下面的理解也不為過：
OOP其實是對物件的屬性和行為的封裝，而AOP對於這點就無從談起，但是AOP是處理某個步驟和階段的，從中進行切面的提取，也就是說，如果幾個或更多個邏輯過程中，有重複的操作行為，AOP就可以提取出來，運用動態代理，實現程序功能的統一維護，這麼說來可能太含蓄，如果說到權限判斷，日誌記錄等，可能就明白了。如果我們單純使用OOP，那麼權限判斷怎麼辦？在每個操作前都加入權限判斷？日誌記錄怎麼辦？在每個方法裡的開始、結束、異常的地方手動新增日誌？所有，如果使用AOP就可以藉助代理完成這些重複的操作，就能夠在邏輯過程中，降低各部分之間的耦合了。二者揚長補短，互相結合最好。
以下詳細了解一些AOP的概念：
•面向（Aspect）：一個關注點的模組化，這個關注點實作可能另外橫切多個物件。事務管理是J2EE應用中一個很好的橫切關注點例子。方面用Spring的Advisor或攔截器實作。
•連接點（Joinpoint）：程式執行過程中明確的點，如方法的呼叫或特定的例外被拋出。
•通知（Advice）：在特定的連接點，AOP框架執行的動作。各種類型的通知包括“around”、“before”和“throws”通知。通知類型將在下面討論。許多AOP框架包括Spring都是以攔截器做通知模型，維護一個「圍繞」連接點的攔截器鏈。
•切入點（Pointcut）：指定一個通知將被引發的一系列連接點的集合。 AOP框架必須允許開發者指定切入點，例如，使用正規表示式。
•引入（Introduction）：新增方法或欄位到被通知的類別。 Spring允許引入新的介面到任何被通知的物件。例如，你可以使用一個引入使任何物件實現IsModified接口，來簡化快取。
•目標對象（Target Object）：包含連接點的對象，也被稱為被通知或被代理對象。
•AOP代理（AOP Proxy）：AOP框架所建立的對象，包含通知。在Spring中，AOP代理可以是JDK動態代理或CGLIB代理。
•編織（Weaving）：組裝方面來創造一個被通知對象。這可以在編譯時完成（例如使用AspectJ編譯器），也可以在執行時完成。 Spring和其他純Java AOP框架一樣，在運作時完成織入。
Spring 中 AOP 代理由 Spring 的 IoC 容器負責產生、管理，其依賴關係也由 IoC 容器負責管理。至於Spring的AOP在專案中具體是怎麼實現的，下篇部落格會以日誌記錄為例進行學習。
