軟件設計師：關于面向對象的一些思考
首先我們要區分一下“基于對象”和“面向對象”的區別。
基于對象，通常指的是對數據的封裝，以及提供一組方法對封裝過的數據操作。比如 C 的 IO 庫中的 FILE * 就可以看成是基于對象的。
面向對象，則在基于對象的基礎上增加了多態性。所謂多態，就是可以用統一的方法對不同的對象進行同樣的操作。當然，這些對象不能完全不同，而需要有一些共性，只有存在了這些共性才可能用同樣的方法去操作它們。我們從 C++ 通常的實現方法的角度來看，A 和 B 在繼承關系上都有共同的祖先 R ，那么我們就可以把 A 和 B 都用對待 R 的控制方法去控制它們。
為什么需要這樣做？
回到一個古老的話題：程序是什么？
程序 = 算法 + 數據結構
在計算機的世界里，數據就是一個個比特的組合；代碼的執行流程就是順序、分支、循環的程序結構的組合。用計算機解決問題，就是用程序結構的組合去重新排列數據的組合，得到結果。為了從龐大的輸入數據（從 bit 的角度上看，任何輸入數據都可能非常的龐大），通過代碼映射到結果數據。我們就必須用合理的數據結構把這些比特數據組合起來，形成數量更少的單元。
這些單元，就是對象。對象同時也包括了對它進行操作的方法。這樣，我們完成了一次封裝，就變成了：
程序 = 基于對象操作的算法 + 以對象為最小單位的數據結構
封裝總是為了減少操作粒度，數據結構上的封裝導致了數據數據的減少，自然減少了問題求解的復雜度；對代碼的封裝使得代碼得以復用，減少了代碼的體積，同樣使問題簡化。
接下來來看 基于對象操作的算法。這種算法必須將操作對象看成是同樣的東西。在沒有對象的層次上，算法操作的都是字節，是同類。但是到了對象的層次，就不一定相同了。這個時候，算法操作的是一個抽象概念的集合。
在面向對象的程序設計中，我們便少不了容器。容器就用來存放一類有共同抽象概念的東西。這里說有共同概念的東西，而沒有說對象。是因為對于算法作用于的集合，里面放的并不是對象實體，而是一個對實體的引用。這個引用表達的是，算法可以對引用的那一頭的東西做些什么，而并不要求那一頭是什么。
比如，我實現一個 GUI 系統（或是一個 3d 世界）。需要實現一個功能——判斷鼠標點選到了什么物件。這里，每個物件提供了一個方法，可以判斷當前鼠標的位置有沒有捕獲（點到）它。
這時最簡單的時候方法是：把所有可以被點選的物件都放在一個容器中，每次遍歷這個容器，查看是哪一個物件捕獲了鼠標。
我們并不需要可被點選的物件都是同類，只需要要求從容器中可以以統一方法訪問每個元素的是否捕獲住鼠標的這個判定方法。
也就是說，把對象置入容器時，只需要讓置入的東西有這一個判定方法即可。了解 COM 的同學應該明白我要說什么了。對，這就是 QueryInterface 的用途。com 的 query interface 就是說，從一個對象里取到一個特定可以做某件事情的接口。通常接下來的代碼會把它放在一個容器里，方便別處的代碼可以干這些事情。
面向對象的本質就是讓對象有多態性，把不同對象以同一特性來歸組，統一處理。至于所謂繼承、虛表、等等概念，只是實現的細節。
說到這里，再說一下 COM ，COM 允許接口繼承 ，但不允許接口多繼承。這一點是從二進制一致性上來考慮的。
為什么沒提實現繼承的事情？因為實現繼承不屬于面向對象的必要因素。而且，現在來看，實現繼承對軟件質量來說，是有負面影響的。因為如果你改寫基類的虛方法，就意味著有可能破壞基類的行為（繼承角度看，基類對象是你這個對象的一部分）。往往基類的實現早于派生類，并不能了解到派生類的需求變化。這樣，在不了解基類設計的前提下，冒然的實現繼承都是有風險的。這不利于軟件的模塊化分離和組件復用。
但是接口繼承又有什么意義呢？以我愚見，絕大多數情況下，同樣對設計沒有意義。但具體到 COM 設計本身，讓每個接口都繼承于 IUnknown 卻是有意義的。這個意義來至于基礎設施的缺乏。我指的是 GC 。在沒有 GC 的環境中，AddRef 和 Release 相當于讓每個對象自己來實現 RC （引用計數）的自動化管理。對于非虛擬機的原生代碼，考慮到 COM 不依賴具體語言，這幾乎是唯一的手段。另外 COM 還支持 apartment 的概念，甚至允許 COM 對象處于不同的機器間，這也使得 GC 實現困難。
QueryInterface 存在于每個 COM 接口中卻有那么一點格格不入。它之所以存在，是因為 COM 接口指針承擔了雙重責任，既指出了一個抽象概念，又引用了對象的實體。但從一個具體算法來看，它只需要對一組相同的抽象概念做操作即可。但它做完操作后，很可能（但不是必須）需要把對象放入另一個不同的集合中，供其它算法操作。這個時候，就需要 QueryInterface 將其轉換為另外一個接口。
但是，從概念上講，讓兩個不相關的接口相互轉換是不合邏輯的。本質上，其實在不相關的接口間轉換做的事情等價于：從一個接口中取得對對象的引用，然后調用這個對象的方法，取到新的接口。
如果去掉了 AddRef Release （依賴 GC ）以及 QueryInterface （只在需要時增加一個接口獲得對象的引用），IUnknown 就什么都不剩了。那么接口繼承也完全不必存在。
回頭再來看程序語言。
C++ 提供了對面向對象的支持，但 C++ 所用的方法（虛表、繼承、多重繼承、虛繼承、等等）只是一種在 C 已有的模型上，追加的一種高效的實現方式而已。它不一定是最高效的方式（雖然很少能做到更高效），也不是最靈活的方式（可以考察 Ruby ）。我想，只用 C++ 寫程序的人最容易犯的錯誤就是認為 C++ 對面向對象的支持的實現本身就是面向對象的本質。如果真的理解了面向對象，在特定需求下可以做出特定的結構來實現它。語言就已經是次要的東西了。
了解你的需求，區分我需要什么和我可以做到什么，對于設計是很重要的。好的設計在于減無可減。
你需要面向對象嗎？你需要 GC 嗎？你需要所有的類都有一個共同的基類嗎？你需要接口可以繼承嗎？你為什么需要這些？
【編輯推薦】
