回想十年前到電腦書店走走，琳琅滿目的書籍就是物件導向程式設計。我想每個資訊工作者家中總有一本 Java 物件導向或 C++ 物件導向這類的書籍，由此可知物件導向程式設計在當時是多麼的轟動與受歡迎。現今資訊系統日漸龐大與複雜，傳統的程式設計方式已經沒有辦法負荷如此的需求，而物件導向可以說是系統發展與成長的產物，我們甚至可以說物件導向程式設計只是結構化程式語言的一種 Design Pattern。
我們來回顧一下物件導向的特性：
- Inheritance - 繼承
- Encapsulation - 封裝
- Polymorphism - 多型
- Abstraction - 抽象
我相信這些特性對於程式設計師而言一點也不陌生，現今大部分的程式語言都有物件導向的能力，我們不可否認物件導向是成功的創舉。
那麼 AOP 又是什麼呢？先來推論一下 AOP 的由來，假設系統在設計時都已經採用物件導向的架構進行開發了，但是當系統發展到一定的規模，為了維護與管理上的便利性，模組化的設計方式是一般人都會思考的議題。
然而模組化該怎麼進行呢？簡單的說，模組化是將系統進行切割，將一個大系統切割為許多小系統，每個小系統僅做好自己份內的事，例如認證模組、快取模組等等。那這跟物件導向似乎扯不上什麼關係，但是我們實際在進行系統模組化的工作中，卻遭遇到系統無法切割或者設計不良的情況發生，這時候我們就需要重新進行系統分析，重構原有的系統。然而 AOP 這時候就出現了，他提供了一套專門拆解系統相依性的分析概念。如果我們說物件導向是程式設計的一種哲學，那麼方面導向 (AOP) 就是物件導向的哲學，也可以說是程式設計哲學中的哲學。因此 AOP 這樣的概念是抽象的，很難有人講的清楚說的明白，只能透過實作來體驗 AOP 的優異。
AOP 概念將功能設計為可以自由的橫向切入系統中，例如開啟Logger的功能、插入認證的功能等等。然而原始的程式碼或業務邏輯不需在乎自身以外的功能，甚至感覺不出來他們的存在，舉個例子：電腦展的時候廠商只負責推銷和販賣商品，他不會在乎場內人數是否過多、交通是否便利、廁所是否夠用，廠商只會把握每一個走到攤位前面的客人，專注的進行販售行為。然而會場的主辦單位則需要控制進場人數，需安排工讀生站在入口計算入場與出場人數，這樣的人數控制機制活生生的被插入(橫切)到系統中，直接影響了經過每一個廠商攤位的人潮。這樣的邏輯就是 AOP 的概念，這些控制人數的工讀生就成為流量控管模組。
雖然 AOP 是抽象的概念，但是系統經過正確的分析之後多少都會包含些許概念在其中，當我們掌握設計要領之後，並能夠設計出更活用的系統。目前比較出名的 AOP 實作有 Spring, JBoos AOP, AsceptJ 等等，然而在 AOP 的發展之下又有另一項產物的誕生，那就是 IoC (控制轉移) 的概念，下次再來介紹有趣的 IoC 哲學。