公共繼承的概念看似簡單，似乎很輕易就浮出水面，然而仔細審度之后，我們會發(fā)現(xiàn)公共繼承的概念實際上包含兩個相互獨立的部分：函數(shù)接口的繼承和函數(shù)實現(xiàn)的繼承。二者之間的差別恰與函數(shù)聲明和函數(shù)實現(xiàn)之間相異之處（本書引言中有介紹）等價。

假如你是一個類設計人員，某些場合下你需要使派生類僅僅繼承基類成員函數(shù)的接口（聲明）。而另一些時候你需要讓派生類繼承將函數(shù)的接口和實現(xiàn)都繼承過來，但還期望可以覆蓋繼承而來的具體實現(xiàn)。另外，你還可能會希望在派生類中繼承函數(shù)的接口和實現(xiàn)，而不允許覆蓋任何內(nèi)容。

為了獲取上述三種選項的直觀感受，可以參考下面的類層次結(jié)構(gòu)實例，該實例用于在圖形程序中表示幾何形狀：

Shape是一個抽象類，純虛函數(shù)draw標示著這一點。因此客戶便無法創(chuàng)建Shape類的實例，只能由Shape類繼承出新的派生類。不過，Shape對所有由它（公共）繼承出的類有著較強的影響，因為

l 成員函數(shù)的接口總會被繼承下來。就像條目32中所解釋的，公共繼承意味著“A是一個B”的關系，因此對于基類成立的任何東西，對于派生類也應成立。由此可知，如果一個函數(shù)對某個類適用，那么它同樣也適用于這個類的派生類。

Shape類中聲名了三個函數(shù)，第一個是draw，用于把當前對象繪制在一個假想的顯示設備上。第二個是error，在成員函數(shù)需要報告錯誤時它將被調(diào)用。第三個是objectID，為當前對象返回一個標識身份的整數(shù)值。每個函數(shù)的聲明方式各不相同：draw是一個純虛函數(shù)，error是一個簡單（非純虛的）虛函數(shù)，objectID是一個非虛函數(shù)。那么這些不同的聲明方式的具體實現(xiàn)又是什么樣的呢？

首先請看純需函數(shù)draw：

純虛函數(shù)最為顯著的兩個特征是：首先，在所有派生出的實體類中，必須要對它們進行重新聲明；其次，純虛函數(shù)在抽象類中一般沒有定義內(nèi)容。融合以上兩點我們可以看出：

l 聲明純虛函數(shù)的目的就是讓派生類僅僅繼承函數(shù)接口。

對于Shape::draw函數(shù)來說上面的分析再恰當不過了，因為“所有的Shape對象必須能夠繪制出來”這一要求十分合理，但是“由Shape類來提供缺省的具體實現(xiàn)”就顯得很牽強了。比如說，繪制一個橢圓的算法與繪制一個長方形大相徑庭。Shape::draw告訴具體派生類的設計者：“你必須要提供一個draw函數(shù)，但是我可不知道你要怎么去實現(xiàn)它。”

順便說一句，為純虛函數(shù)提供一個定義并沒有被C++所禁止。也就是說，你可以為Shape::draw提供一套具體實現(xiàn)，而C++不會報錯，但是在調(diào)用這種函數(shù)時，必須要加上類名：

上文所述的這一C++特征，除了作為你在雞尾酒會上的談資以外，似乎真正的用處很有限。然而就像你在下文中見到的一樣，這一特征也有一定的用武之地，它可以為簡單（非純）虛函數(shù)提供“超常安全”的默認具體實現(xiàn)。

簡單虛函數(shù)背后隱藏的內(nèi)情與純虛函數(shù)有些許不同。一般情況下，派生類繼承函數(shù)接口，但是簡單虛函數(shù)提供了一個具體實現(xiàn)，派生類中可以覆蓋這一實現(xiàn)。如果你稍加思索，你就會發(fā)現(xiàn)：

l 聲明簡單虛函數(shù)的目的就是：讓派生類繼承函數(shù)接口的同時，繼承一個默認的具體實現(xiàn)。

請觀察以下情形中的Shape::error：

接口要求每個類必須要提供一個error函數(shù)，以便在程序出錯時調(diào)用，但是每個類都有適合自己的處理錯誤的方法。如果一個類并不想提供特殊的錯誤處理機制，那么它就可以返回調(diào)用Shape中提供的默認機制。也就是說，Shape::error的聲明就是告訴派生類的設計者，“你應該提供一個error函數(shù)，但是如果你不想自己編寫，那么也可以借助于Shape類的默認版本。”

實踐表明，允許簡單虛函數(shù)同時提供函數(shù)接口和默認實現(xiàn)是不安全的。至于原因，你可以設想一個XYZ航空公司的航班層次結(jié)構(gòu)。XYZ只有兩種飛機：A型和B型，它們飛行的航線是完全一致的。于是，XYZ這樣設計了層次結(jié)構(gòu)：

此處Airplane::fly聲明為虛函數(shù)，這是為了表明所有飛機必須要提供一個fly函數(shù)，同時也基于以下事實：理論上講，不同型號的飛機需要提供不同版本的fly函數(shù)實現(xiàn)。然而，為了避免在ModelA和ModelB中出現(xiàn)同樣的代碼，我們將默認的飛行行為放置在Airplane::fly中，由ModelA和ModelB來繼承。

這是一個經(jīng)典的面向?qū)ο笤O計方案。當兩個類共享同一特征（即它們實現(xiàn)fly的方式）時，我們將這一共同特征移動到一個基類中，然后由兩個派生類來繼承這一共同特征。這一設計方案使得共同特征顯性化，避免了代碼重復，為未來的更新工作提供了便利，減輕了長期維護的負擔——所有的一切都是面向?qū)ο蠹夹g極力倡導的。XYZ航空公司應該感到十分驕傲了。

現(xiàn)在請設想：XYZ公司有了新的業(yè)務拓展，他們決定引進一款新型飛機——C型。C型飛機在某些方面與A型和B型有著本質(zhì)的區(qū)別，尤其是，C型飛機的飛行方式與前兩者完全不同。

XYZ的程序員將C型飛機添加進層次結(jié)構(gòu)，但是由于他們急于讓新型飛機投入運營，他們忘記了重定義fly函數(shù)：

于是，在他們的代碼中將會遇到下面代碼中類似的問題：

這將是一場災難：因為此處做了一項可怕的嘗試，那就是讓ModelC以ModelA和ModelB的形式飛行。你將為這一嘗試付出慘痛的代價。

問題的癥結(jié)不在于Airplane::fly使用默認的行為，而是在沒有顯式說明的情況下ModelC需要繼承該行為的情況下就繼承了它。幸運的是以下這一點我們很容易做到：根據(jù)需要為派生類提供默認行為，如果派生類沒有顯式說明，那么就不為其提供。做到這一點的秘訣是：切斷虛函數(shù)的接口和默認實現(xiàn)之間的聯(lián)系。以下是一種實現(xiàn)方法：

請注意這里的Airplane::fly是如何轉(zhuǎn)變成一個純虛函數(shù)的。它為飛行提供了接口。默認實現(xiàn)在Airplane類中也會出現(xiàn)，但是現(xiàn)在它是以一個獨立函數(shù)的形式存在的——defaultFly。諸如ModelA和ModelB此類需要使用默認行為的類，只需要簡單地在它們的fly函數(shù)中內(nèi)聯(lián)調(diào)用defaultFly即可（請參見條目30中介紹的關于內(nèi)聯(lián)和虛函數(shù)之間的聯(lián)系）：

對于ModelC類而言，繼承不恰當?shù)?span style="font-family:"Courier New";">fly實現(xiàn)是根本不可能的，因為Airplane中的純虛函數(shù)fly強制ModelC提供自己版本的fly。

這一方案亦非天衣無縫（程序員仍然會“復制/粘貼”出新的麻煩），但是它至少要比原始的設計方案更可靠。至于Airplane::defaultFly，由于此處它是Airplane及其派生類真實的實現(xiàn)。客戶只需要關注飛機可以飛行，而無須理會飛行功能是如何實現(xiàn)的。

Airplane::defaultFly是一個非虛函數(shù)，這一點同樣重要。這是因為任何派生類都不應該去重定義這一函數(shù)，這是條目36所致力于講述的議題。如果defaultFly是虛函數(shù)，那么你將會遇到一個遞歸的問題：如果一些派生類忘記了重定義defaultFly，那么它會怎樣呢？

類似于上文中介紹的fly和defaultFly函數(shù)，為接口和默認實現(xiàn)分別提供不同函數(shù)的方法，受到了一些人的質(zhì)疑。他們指出，盡管他們不懷疑將接口和默認實現(xiàn)分開處理的必要性，但是這樣做導致一些近親函數(shù)名字，從而污染了類名字空間。那么如何解決這一看上去自相矛盾的難題呢？我們知道純虛函數(shù)在具體的派生類中必須得到重新聲明，但是純虛函數(shù)自身也可以有具體實現(xiàn)，借助這一點問題便迎刃而解。下面代碼中的Airplane層次結(jié)構(gòu)就利用了“純虛函數(shù)自身可以被定義”這一點：

這一設計方案與前一個幾乎是一致的。只是這里用純虛函數(shù)Airplane::fly代替了獨立函數(shù)Airplane::defaultFly。從本質(zhì)上講，這里的fly被分割成了兩個基本的組成部分，它的聲明確定它的接口，而它的定義確定它的默認行為（派生類可以使用這一定義，但只有在現(xiàn)實請求的前提下才可以）。然而將fly和defaultFly合并起來，你就失去了將這兩個函數(shù)置于不同保護層次的能力：原先受保護的代碼（defaultFly中的代碼）現(xiàn)在是公共的了（因為這些代碼移動到了fly中）。

最后，讓我們把話題轉(zhuǎn)向Shape中的非虛函數(shù)——objectID：

當一個成員函數(shù)不是虛函數(shù)時，你不應該期待它會在不同的派生類中存在不同的行為。事實上，非虛成員函數(shù)確立了一個“個性化壁壘”，因為它確保了無論派生類在其他部分如何進行個性化，本函數(shù)所確定的行為不能被改變。也就是說：

l 聲明一個非虛函數(shù)的目的就是讓派生類繼承這一函數(shù)的接口，同時強制繼承其固定的具體實現(xiàn)。

你可以把shape::objectID的聲明想象成：每個Shape對象都有一個函數(shù)能生成“對象身份標識”的函數(shù)。這一“對象身份標識”總是以同一方式運行。這一方式由Shape::objectID的定義確定，任何派生類都不能償試更改這一方式。因為一個非虛函數(shù)就確定了一個“個性化壁壘”，所以在任何的派生類中都不允許重定義該函數(shù)，這一點將在條目36中詳細講解。

純虛函數(shù)，簡單虛函數(shù)和非虛函數(shù)，不同的聲明方式使你能夠精確地指定你的派生類需要繼承什么：是僅僅繼承接口，還是同時繼承接口和實現(xiàn)，抑或接口和一套固定的實現(xiàn)。由于這些不同種類的聲明意味著彼此在基礎層面存在著不同，因此你在聲明成員函數(shù)時，一定要仔細斟酌。如果你這樣做了，那么你將避免缺乏經(jīng)驗的類設計人員常犯的兩類錯誤：

首先，第一類錯誤是：將所有函數(shù)都聲明為非虛的。這樣做可以說斷送了派生類進行拓展的后路。非虛析構(gòu)函數(shù)更是陷阱重重（參見條目7）。當然，設計一個不需要作為基類的類無可厚非，這種情況下，清一色的一組非虛函數(shù)也是合乎情理的。然而，由于人們常常忽視虛函數(shù)和非虛函數(shù)之間的差異，還有對于“虛函數(shù)會對性能產(chǎn)生影響”的無端猜疑，導致我們的程序中充斥著過量的完全不包含虛函數(shù)的類。但事實上，幾乎每個需要充當基類的類都需要虛函數(shù)的支持。（同樣請參見條目7）

如果你談到虛函數(shù)的性能開銷問題，請允許我引用基于經(jīng)驗主義的“80-20法則”（同樣參見條目30），在一個典型的程序中，80%的運行時間將花費在20%的代碼上。這一法則十分重要，因為它意味著在一般情況下，80%的虛函數(shù)調(diào)用將不會對你的程序的整體性能造成任何影響。與其為虛函數(shù)是否會帶來無法承受的性能開銷而顧忌重重，還不如把精力放在程序中真正會帶來影響的那20%上。

另一個一般的問題是：將所有的成員函數(shù)都聲明為虛函數(shù)。有時候這么做是正確的——條目31中的接口類就是證據(jù)。然而，這樣做給人的印象就是這個類的設計者缺乏主心骨。在派生類中一些函數(shù)不應該進行重定義，你必須要通過將這些函數(shù)聲明為非虛函數(shù)才能確保這一點。你應該清楚，并不是讓客戶去重定義所有的函數(shù)，你的類就成了萬能的了。如果你的類中包含個性化壁壘，那么就應該大膽的將其聲明為非虛函數(shù)。

時刻牢記

l 接口繼承與實現(xiàn)繼承存在著不同。在公共繼承體系下，派生類總是繼承基類的接口。

l 純虛函數(shù)要求派生類僅繼承接口。

l 簡單（非純）虛函數(shù)要求派生類在繼承接口的同時繼承一個默認的實現(xiàn)。

l 非虛函數(shù)要求派生類繼承接口和強制固定內(nèi)容的實現(xiàn)。