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