在本人之前的《Component/Service Oriented Software System Development Thinking 》一文中，我將包括BinaryLevel和Source Code Level的軟體模組統稱為Component。這種分類方式，和傳統的對Component的一般定義應該說並不是十分一致。本文就是要對我為什麼要這樣分類作一些補充解釋。 - 傳統的定義中，一般認為，Component Oriented和Object Oriented有本質區別，在O'Reilly的《Programming .Net Component》一書中，列舉了兩者的主要區別和Component Oriented的基本原設計準則。沒看過的讀者可以下載下來看看，這裡給的連結只包含該書了第一章，當然，這裡說的區別和設計準則是包含在這一章裡的。 區別：1. Building Blocks Versus Monolithic Applications - 多程式集還是單一程式集2. Interfaces Versus Inheritance - 黑盒還是白盒 設計準則：1. Separation of cnterface and implementation2. Binary compatibility3. Language idependency4. Location transparency5. Concurrency management6. Version Control7. Component-based security -
那麼，我為何將這兩個原本有區別，區別似乎還不是很小的概念歸在一個統一的概念-“Component”中呢？ 首先我們來談談，上面提到的兩個主要區別。 原書的作者的主要觀點是，組件總應該是語言無關的二進位層級的黑盒模型，而OO則一般是語言相關的原始碼層級的白盒模型。接著又說到，組件的重用，一般是不去關心其內部細節，而以大顆粒的功能調用或類繼承來使用；而OO則可以以細顆粒去繼承，並且可以方便的通過設計模式的運用組合、攔截函數調用，插入代碼、修改內部細節等等，類的繼承，也可以是細顆粒的。因此，說兩者有本質區別。 從作者考慮這個問題的角度，也是傳統的組件定義的角度來說，以上的論點當然是不錯的。但是，
有一項思想或者說技術的出現，很大程度上打破了以上的界限，是什麼技術呢？您可能已經詞到嘴邊了，沒錯
——AOP。 - 關於AOP的基礎思想介紹，我這裡就不多說了，如果您還不是很瞭解，可以在部落格園站內搜尋一下AOP。我這裡要為您說明的是，為什麼有了AOP的思想，以上這種CO和OO的界限和區別就大大減弱了呢？ 當然這裡我要特別提一下，我這裡指的AOP，主要指有二進位層級織入能力的AOP，如Teddy所寫的一個.Net下的AOP工具AspectWeaver，而不僅僅是像Castle.Aspect#這樣的基於DynamicProxy的AOP實現。 因為AOP的二進位層級的織入能力，更直白一點說，是AOP使得操作二進位層級的組件或者說程式集就和操作原始碼層級的模組一樣容易的能力，使得只要您願意，就可以像有原始碼的組件一樣使用二進位的程式集。在二進位層級將一個程式集分解成多個程式集，或者多個程式集者病程一個程式集同樣是輕而易舉。所謂黑盒還是白盒的區別，也就變得沒有太大的意義了。現在都可以看作白盒。只要相應的原始碼能夠編譯成相互相容和可識別的二進位程式集，那麼我們就能在二進位層級對程式模組進行任意的重用和改造。 當然，上面所列的組件化設計的基本原則，現在還是適用的。同時，這種二進位層級的細節操縱能力，使得AOP不但能夠使用OO中所有可以使用的工具和設計思想，還是一個超集，可以做到許多超越OO限制的功能，如Mixin，介面實現，基類變更，靜態代碼攔截等等/插入/刪除等等，感興趣的朋友可以自查看相應的資料。 -
正是因為AOP的這種特殊能力，很大程度上破除了二進位組件和OO組件的界限，更將帶來軟體開發思想，可重用軟體設計等的巨大變革，和很多以前實現不了的可能性變為現實。這樣的變革的大致風貌我在之前的文章《重新詮釋AOP》中已有些許描述，在稍後的《Looking into Component》中，我也將會有進一步闡述。敬請期待！
