AOP─面向導向程式設計

彌補OOP不足的缺憾

當OO（Objects-Oriented，物件導向）成為軟體開發的主流時，令人好奇的是，接下來的軟體該如何開發？軟體開發者將系統設想成一個實體團隊，且實體與實體間彼此都相互作用，這樣的運作不但能縮短作業時程，且能處理更大、更複雜的系統。因此，在改變需求方面，用OOP所撰寫的程式對於加速程式發展的時程有很深遠的影響。
相較於OOP只能靜態的（Static）修改系統程式，AOP（Aspect-Oriented Programming，面向導向程式設計）不但允許軟體開發人員能做動態的修改，甚至不需修改原本靜態的Model，完全彌補了OOP不足的缺憾。AOP最令人讚賞的是，開發人員根本不需要知道原本的程式碼為何，就可以直接將某段附加的程式碼放置在一個獨立位置，且不需將它的資訊提供給現有的Model。但如果是使用OO，則情況就不同了。
相信大多數的軟體開發人員應該都有用過Servlet撰寫簡單的Web Applications的經驗。在“Servlet接受HTML的輸入值（Values）傳送給某個物件作處理，並回傳結果給User。”的這個動作，對Servlet而言或許相當簡單，只需幾行程式碼就能達到要求。但是，當程式被要求加入“額外的需求”條件值，如例外處理、安全性處理和儲存Log記錄時，程式碼就會被每一次的額外的需求擴展三至四次。
在標準的OO程式寫作中，軟體開發人員都會用System.out.println做為Trace程式碼的動作。但是，若在許多地方都置入System.out.println，程式就會顯得凌亂不堪。反觀在AOP的架構中，開發人員只須利用一個“Aspect”就可以取代所有System.out.println。開發人員可將想要儲存的Log記錄全部包裝在一個Aspect裡，就能指定任何的Class在被呼叫（Called）或被衍生（Invoked）的之前或之後執行儲存Log記錄的動作。
在AspectJ的範例中可以如圖一與圖二的操作，Aspect的實作我們稱為Advice，在Method呼叫或離開的地方稱為Joinpoint，而實際應用到的Method則稱為Pointcut。
AOP目前最成熟且最可得到的框架（Framework）就屬AspectJ。AspectJ設定大多數框架所跟隨的標準，但AOP的設計師們也在其實現中的JAVA語言不斷增加新的關鍵字，雖然這些新的語法並非太難學習，但這也意謂著，軟體開發人員為了學習及使用新的語法而必須不斷更改編譯器與編輯器。然而，這樣的遊戲規則在大團隊裡是行不通的，團隊若是冒然使用AOP技術於現有的Project中，定會增加不必要的困擾，團隊需要的框架是要能夠輕易引入，且對Project的發展不致產生嚴重影響，如JBoss AOP、Nanning、和Aspectwerkz都符合這樣的條件。

增加軟體功能性的聰明新方法

儘管如此，引入AOP不啻為增加軟體功能性的一種聰明新方法，再者，AOP還有其他優點，包括程式碼的重複使用，就提昇了系統維護的便利性；但若是誤將AOP用在系統維護上，則將造成嚴重的後果。因此，了解如何正確地使用AOP，對軟體開發人員而言是一門非常重要的課題。
目前就大多數具規模或是臨界生產系統方面，使用AOP的技術還未純熟，但當語言支援增加時，AOP將會更容易被推廣及採用。目前在.NET領域內的幾種AOP框架，當中的每一個AOP框架都有其自己的方法和屬性。
倘若AOP能被正確的使用，其所能帶來的好處絕對大過壞處。甚至還能幫助您取得一般程式寫作所不能得到的意外結果。
參考資料
‧http://www.onjava.com‧http://www.msdn.com
‧Program Slicing Tool for Effective Software Evolution Using Aspect-Oriented Technique（Takashi Ishio, Shinji Kusumoto, Katsuro Inoue）