fbpx

From OOP to AOP - 從物件導向到方面導向程式設計

回想十年前到電腦書店走走,琳琅滿目的書籍就是物件導向程式設計。我想每個資訊工作者家中總有一本 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 哲學。

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *

這個網站採用 Akismet 服務減少垃圾留言。進一步了解 Akismet 如何處理網站訪客的留言資料