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