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

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

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

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

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

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

首先請看純需函數draw：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

對于ModelC類而言，繼承不恰當的fly實現是根本不可能的，因為Airplane中的純虛函數fly強制ModelC提供自己版本的fly。

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

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

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

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

最后，讓我們把話題轉向Shape中的非虛函數——objectID：

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

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

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

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

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

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

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

時刻牢記

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

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

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

l 非虛函數要求派生類繼承接口和強制固定內容的實現。