公共繼承的概念看似簡單，似乎很輕易就浮出水面，然而仔細(xì)審度之后，我們會發(fā)現(xiàn)公共繼承的概念實(shí)際上包含兩個(gè)相互獨(dú)立的部分：函數(shù)接口的繼承和函數(shù)實(shí)現(xiàn)的繼承。二者之間的差別恰與函數(shù)聲明和函數(shù)實(shí)現(xiàn)之間相異之處（本書引言中有介紹）等價(jià)。
假如你是一個(gè)類設(shè)計(jì)人員，某些場合下你需要使派生類僅僅繼承基類成員函數(shù)的接口（聲明）。而另一些時(shí)候你需要讓派生類繼承將函數(shù)的接口和實(shí)現(xiàn)都繼承過來，但還期望可以覆蓋繼承而來的具體實(shí)現(xiàn)。另外，你還可能會希望在派生類中繼承函數(shù)的接口和實(shí)現(xiàn)，而不允許覆蓋任何內(nèi)容。
為了獲取上述三種選項(xiàng)的直觀感受，可以參考下面的類層次結(jié)構(gòu)實(shí)例，該實(shí)例用于在圖形程序中表示幾何形狀：
class Shape {
public:
virtual void draw() const = 0;
virtual void error(const std::string& msg);
int objectID() const;
...
};
class Rectangle: public Shape { ... };
class Ellipse: public Shape { ... };
Shape是一個(gè)抽象類，純虛函數(shù)draw標(biāo)示著這一點(diǎn)。因此客戶便無法創(chuàng)建Shape類的實(shí)例，只能由Shape類繼承出新的派生類。不過，Shape對所有由它（公共）繼承出的類有著較強(qiáng)的影響，因?yàn)?/p>
l 成員函數(shù)的接口總會被繼承下來。就像條目32中所解釋的，公共繼承意味著“A是一個(gè)B”的關(guān)系，因此對于基類成立的任何東西，對于派生類也應(yīng)成立。由此可知，如果一個(gè)函數(shù)對某個(gè)類適用，那么它同樣也適用于這個(gè)類的派生類。
Shape類中聲名了三個(gè)函數(shù)，第一個(gè)是draw，用于把當(dāng)前對象繪制在一個(gè)假想的顯示設(shè)備上。第二個(gè)是error，在成員函數(shù)需要報(bào)告錯(cuò)誤時(shí)它將被調(diào)用。第三個(gè)是objectID，為當(dāng)前對象返回一個(gè)標(biāo)識身份的整數(shù)值。每個(gè)函數(shù)的聲明方式各不相同：draw是一個(gè)純虛函數(shù)，error是一個(gè)簡單（非純虛的）虛函數(shù)，objectID是一個(gè)非虛函數(shù)。那么這些不同的聲明方式的具體實(shí)現(xiàn)又是什么樣的呢？
首先請看純需函數(shù)draw：
class Shape {
public:
virtual void draw() const = 0;
...
};
純虛函數(shù)最為顯著的兩個(gè)特征是：首先，在所有派生出的實(shí)體類中，必須要對它們進(jìn)行重新聲明；其次，純虛函數(shù)在抽象類中一般沒有定義內(nèi)容。融合以上兩點(diǎn)我們可以看出：
l 聲明純虛函數(shù)的目的就是讓派生類僅僅繼承函數(shù)接口。
對于Shape::draw函數(shù)來說上面的分析再恰當(dāng)不過了，因?yàn)?#8220;所有的Shape對象必須能夠繪制出來”這一要求十分合理，但是“由Shape類來提供缺省的具體實(shí)現(xiàn)”就顯得很牽強(qiáng)了。比如說，繪制一個(gè)橢圓的算法與繪制一個(gè)長方形大相徑庭。Shape::draw告訴具體派生類的設(shè)計(jì)者：“你必須要提供一個(gè)draw函數(shù)，但是我可不知道你要怎么去實(shí)現(xiàn)它。”
順便說一句，為純虛函數(shù)提供一個(gè)定義并沒有被C++所禁止。也就是說，你可以為Shape::draw提供一套具體實(shí)現(xiàn)，而C++不會報(bào)錯(cuò)，但是在調(diào)用這種函數(shù)時(shí)，必須要加上類名：
Shape *ps = new Shape; // 錯(cuò)！Shape是抽象類
Shape *ps1 = new Rectangle; // 正確
ps1->draw(); // 調(diào)用Rectangle::draw
Shape *ps2 = new Ellipse; // 正確
ps2->draw(); // 調(diào)用Ellipse::draw
ps1->Shape::draw(); // 調(diào)用Shape::draw
ps2->Shape::draw(); // 調(diào)用 Shape::draw
上文所述的這一C++特征，除了作為你在雞尾酒會上的談資以外，似乎真正的用處很有限。然而就像你在下文中見到的一樣，這一特征也有一定的用武之地，它可以為簡單（非純）虛函數(shù)提供“超常安全”的默認(rèn)具體實(shí)現(xiàn)。
簡單虛函數(shù)背后隱藏的內(nèi)情與純虛函數(shù)有些許不同。一般情況下，派生類繼承函數(shù)接口，但是簡單虛函數(shù)提供了一個(gè)具體實(shí)現(xiàn)，派生類中可以覆蓋這一實(shí)現(xiàn)。如果你稍加思索，你就會發(fā)現(xiàn)：
l 聲明簡單虛函數(shù)的目的就是：讓派生類繼承函數(shù)接口的同時(shí)，繼承一個(gè)默認(rèn)的具體實(shí)現(xiàn)。
請觀察以下情形中的Shape::error：
class Shape {
public:
virtual void error(const std::string& msg);
...
};
接口要求每個(gè)類必須要提供一個(gè)error函數(shù)，以便在程序出錯(cuò)時(shí)調(diào)用，但是每個(gè)類都有適合自己的處理錯(cuò)誤的方法。如果一個(gè)類并不想提供特殊的錯(cuò)誤處理機(jī)制，那么它就可以返回調(diào)用Shape中提供的默認(rèn)機(jī)制。也就是說，Shape::error的聲明就是告訴派生類的設(shè)計(jì)者，“你應(yīng)該提供一個(gè)error函數(shù)，但是如果你不想自己編寫，那么也可以借助于Shape類的默認(rèn)版本。”
實(shí)踐表明，允許簡單虛函數(shù)同時(shí)提供函數(shù)接口和默認(rèn)實(shí)現(xiàn)是不安全的。至于原因，你可以設(shè)想一個(gè)XYZ航空公司的航班層次結(jié)構(gòu)。XYZ只有兩種飛機(jī)：A型和B型，它們飛行的航線是完全一致的。于是，XYZ這樣設(shè)計(jì)了層次結(jié)構(gòu)：
class Airport { ... }; // 表示飛機(jī)場
class Airplane {
public:
virtual void fly(const Airport& destination);
...
};
void Airplane::fly(const Airport& destination)
{
默認(rèn)代碼：使飛機(jī)抵達(dá)給定的目的地
}
class ModelA: public Airplane { ... };
class ModelB: public Airplane { ... };
此處Airplane::fly聲明為虛函數(shù)，這是為了表明所有飛機(jī)必須要提供一個(gè)fly函數(shù)，同時(shí)也基于以下事實(shí)：理論上講，不同型號的飛機(jī)需要提供不同版本的fly函數(shù)實(shí)現(xiàn)。然而，為了避免在ModelA和ModelB中出現(xiàn)同樣的代碼，我們將默認(rèn)的飛行行為放置在Airplane::fly中，由ModelA和ModelB來繼承。
這是一個(gè)經(jīng)典的面向?qū)ο笤O(shè)計(jì)方案。當(dāng)兩個(gè)類共享同一特征（即它們實(shí)現(xiàn)fly的方式）時(shí)，我們將這一共同特征移動(dòng)到一個(gè)基類中，然后由兩個(gè)派生類來繼承這一共同特征。這一設(shè)計(jì)方案使得共同特征顯性化，避免了代碼重復(fù)，為未來的更新工作提供了便利，減輕了長期維護(hù)的負(fù)擔(dān)——所有的一切都是面向?qū)ο蠹夹g(shù)極力倡導(dǎo)的。XYZ航空公司應(yīng)該感到十分驕傲了。
現(xiàn)在請?jiān)O(shè)想：XYZ公司有了新的業(yè)務(wù)拓展，他們決定引進(jìn)一款新型飛機(jī)——C型。C型飛機(jī)在某些方面與A型和B型有著本質(zhì)的區(qū)別，尤其是，C型飛機(jī)的飛行方式與前兩者完全不同。
XYZ的程序員將C型飛機(jī)添加進(jìn)層次結(jié)構(gòu)，但是由于他們急于讓新型飛機(jī)投入運(yùn)營，他們忘記了重定義fly函數(shù)：
class ModelC: public Airplane {
... // 沒有聲明任何fly函數(shù)
};
于是，在他們的代碼中將會遇到下面代碼中類似的問題：
Airport PDX(...); // PDX是我家附近一個(gè)飛機(jī)場
Airplane *pa = new ModelC;
...
pa->fly(PDX); // 調(diào)用了Airplane::fly！
這將是一場災(zāi)難：因?yàn)榇颂幾隽艘豁?xiàng)可怕的嘗試，那就是讓ModelC以ModelA和ModelB的形式飛行。你將為這一嘗試付出慘痛的代價(jià)。
問題的癥結(jié)不在于Airplane::fly使用默認(rèn)的行為，而是在沒有顯式說明的情況下ModelC需要繼承該行為的情況下就繼承了它。幸運(yùn)的是以下這一點(diǎn)我們很容易做到：根據(jù)需要為派生類提供默認(rèn)行為，如果派生類沒有顯式說明，那么就不為其提供。做到這一點(diǎn)的秘訣是：切斷虛函數(shù)的接口和默認(rèn)實(shí)現(xiàn)之間的聯(lián)系。以下是一種實(shí)現(xiàn)方法：
class Airplane {
public:
virtual void fly(const Airport& destination) = 0;
...
protected:
void defaultFly(const Airport& destination);
};
void Airplane::defaultFly(const Airport& destination)
{
默認(rèn)代碼：使飛機(jī)抵達(dá)給定目的地
}
請注意這里的Airplane::fly是如何轉(zhuǎn)變成一個(gè)純虛函數(shù)的。它為飛行提供了接口。默認(rèn)實(shí)現(xiàn)在Airplane類中也會出現(xiàn)，但是現(xiàn)在它是以一個(gè)獨(dú)立函數(shù)的形式存在的——defaultFly。諸如ModelA和ModelB此類需要使用默認(rèn)行為的類，只需要簡單地在它們的fly函數(shù)中內(nèi)聯(lián)調(diào)用defaultFly即可（請參見條目30中介紹的關(guān)于內(nèi)聯(lián)和虛函數(shù)之間的聯(lián)系）：
class ModelA: public Airplane {
public:
virtual void fly(const Airport& destination)
{ defaultFly(destination); }
...
};
class ModelB: public Airplane {
public:
virtual void fly(const Airport& destination)
{ defaultFly(destination); }
...
};
對于ModelC類而言，繼承不恰當(dāng)?shù)?span style="font-family:"Courier New";">fly實(shí)現(xiàn)是根本不可能的，因?yàn)?span style="font-family: "Courier New";">Airplane中的純虛函數(shù)fly強(qiáng)制ModelC提供自己版本的fly。
class ModelC: public Airplane {
public:
virtual void fly(const Airport& destination);
...
};
void ModelC::fly(const Airport& destination)
{
使C型飛機(jī)抵達(dá)目的地的代碼
}
這一方案亦非天衣無縫（程序員仍然會“復(fù)制/粘貼”出新的麻煩），但是它至少要比原始的設(shè)計(jì)方案更可靠。至于Airplane::defaultFly，由于此處它是Airplane及其派生類真實(shí)的實(shí)現(xiàn)?？蛻糁恍枰P(guān)注飛機(jī)可以飛行，而無須理會飛行功能是如何實(shí)現(xiàn)的。
Airplane::defaultFly是一個(gè)非虛函數(shù)，這一點(diǎn)同樣重要。這是因?yàn)槿魏闻缮惗疾粦?yīng)該去重定義這一函數(shù)，這是條目36所致力于講述的議題。如果defaultFly是虛函數(shù)，那么你將會遇到一個(gè)遞歸的問題：如果一些派生類忘記了重定義defaultFly，那么它會怎樣呢？
類似于上文中介紹的fly和defaultFly函數(shù)，為接口和默認(rèn)實(shí)現(xiàn)分別提供不同函數(shù)的方法，受到了一些人的質(zhì)疑。他們指出，盡管他們不懷疑將接口和默認(rèn)實(shí)現(xiàn)分開處理的必要性，但是這樣做導(dǎo)致一些近親函數(shù)名字，從而污染了類名字空間。那么如何解決這一看上去自相矛盾的難題呢？我們知道純虛函數(shù)在具體的派生類中必須得到重新聲明，但是純虛函數(shù)自身也可以有具體實(shí)現(xiàn)，借助這一點(diǎn)問題便迎刃而解。下面代碼中的Airplane層次結(jié)構(gòu)就利用了“純虛函數(shù)自身可以被定義”這一點(diǎn)：
class Airplane {
public:
virtual void fly(const Airport& destination) = 0;
...
};
void Airplane::fly(const Airport& destination)
{ // 純虛函數(shù)的具體實(shí)現(xiàn)
默認(rèn)代碼：使飛機(jī)抵達(dá)給定的目的地
}
class ModelA: public Airplane {
public:
virtual void fly(const Airport& destination)
{ Airplane::fly(destination); }
...
};
class ModelB: public Airplane {
public:
virtual void fly(const Airport& destination)
{ Airplane::fly(destination); }
...
};
class ModelC: public Airplane {
public:
virtual void fly(const Airport& destination);
...
};
void ModelC::fly(const Airport& destination)
{
使C型飛機(jī)抵達(dá)目的地的代碼
}
這一設(shè)計(jì)方案與前一個(gè)幾乎是一致的。只是這里用純虛函數(shù)Airplane::fly代替了獨(dú)立函數(shù)Airplane::defaultFly。從本質(zhì)上講，這里的fly被分割成了兩個(gè)基本的組成部分，它的聲明確定它的接口，而它的定義確定它的默認(rèn)行為（派生類可以使用這一定義，但只有在現(xiàn)實(shí)請求的前提下才可以）。然而將fly和defaultFly合并起來，你就失去了將這兩個(gè)函數(shù)置于不同保護(hù)層次的能力：原先受保護(hù)的代碼（defaultFly中的代碼）現(xiàn)在是公共的了（因?yàn)檫@些代碼移動(dòng)到了fly中）。
最后，讓我們把話題轉(zhuǎn)向Shape中的非虛函數(shù)——objectID：
class Shape {
public:
int objectID() const;
...
};
當(dāng)一個(gè)成員函數(shù)不是虛函數(shù)時(shí)，你不應(yīng)該期待它會在不同的派生類中存在不同的行為。事實(shí)上，非虛成員函數(shù)確立了一個(gè)“個(gè)性化壁壘”，因?yàn)樗_保了無論派生類在其他部分如何進(jìn)行個(gè)性化，本函數(shù)所確定的行為不能被改變。也就是說：
l 聲明一個(gè)非虛函數(shù)的目的就是讓派生類繼承這一函數(shù)的接口，同時(shí)強(qiáng)制繼承其固定的具體實(shí)現(xiàn)。
你可以把shape::objectID的聲明想象成：每個(gè)Shape對象都有一個(gè)函數(shù)能生成“對象身份標(biāo)識”的函數(shù)。這一“對象身份標(biāo)識”總是以同一方式運(yùn)行。這一方式由Shape::objectID的定義確定，任何派生類都不能償試更改這一方式。因?yàn)橐粋€(gè)非虛函數(shù)就確定了一個(gè)“個(gè)性化壁壘”，所以在任何的派生類中都不允許重定義該函數(shù)，這一點(diǎn)將在條目36中詳細(xì)講解。
純虛函數(shù)，簡單虛函數(shù)和非虛函數(shù)，不同的聲明方式使你能夠精確地指定你的派生類需要繼承什么：是僅僅繼承接口，還是同時(shí)繼承接口和實(shí)現(xiàn)，抑或接口和一套固定的實(shí)現(xiàn)。由于這些不同種類的聲明意味著彼此在基礎(chǔ)層面存在著不同，因此你在聲明成員函數(shù)時(shí)，一定要仔細(xì)斟酌。如果你這樣做了，那么你將避免缺乏經(jīng)驗(yàn)的類設(shè)計(jì)人員常犯的兩類錯(cuò)誤：
首先，第一類錯(cuò)誤是：將所有函數(shù)都聲明為非虛的。這樣做可以說斷送了派生類進(jìn)行拓展的后路。非虛析構(gòu)函數(shù)更是陷阱重重（參見條目7）。當(dāng)然，設(shè)計(jì)一個(gè)不需要作為基類的類無可厚非，這種情況下，清一色的一組非虛函數(shù)也是合乎情理的。然而，由于人們常常忽視虛函數(shù)和非虛函數(shù)之間的差異，還有對于“虛函數(shù)會對性能產(chǎn)生影響”的無端猜疑，導(dǎo)致我們的程序中充斥著過量的完全不包含虛函數(shù)的類。但事實(shí)上，幾乎每個(gè)需要充當(dāng)基類的類都需要虛函數(shù)的支持。（同樣請參見條目7）
如果你談到虛函數(shù)的性能開銷問題，請?jiān)试S我引用基于經(jīng)驗(yàn)主義的“80-20法則”（同樣參見條目30），在一個(gè)典型的程序中，80%的運(yùn)行時(shí)間將花費(fèi)在20%的代碼上。這一法則十分重要，因?yàn)樗馕吨谝话闱闆r下，80%的虛函數(shù)調(diào)用將不會對你的程序的整體性能造成任何影響。與其為虛函數(shù)是否會帶來無法承受的性能開銷而顧忌重重，還不如把精力放在程序中真正會帶來影響的那20%上。
另一個(gè)一般的問題是：將所有的成員函數(shù)都聲明為虛函數(shù)。有時(shí)候這么做是正確的——條目31中的接口類就是證據(jù)。然而，這樣做給人的印象就是這個(gè)類的設(shè)計(jì)者缺乏主心骨。在派生類中一些函數(shù)不應(yīng)該進(jìn)行重定義，你必須要通過將這些函數(shù)聲明為非虛函數(shù)才能確保這一點(diǎn)。你應(yīng)該清楚，并不是讓客戶去重定義所有的函數(shù)，你的類就成了萬能的了。如果你的類中包含個(gè)性化壁壘，那么就應(yīng)該大膽的將其聲明為非虛函數(shù)。
時(shí)刻牢記
l 接口繼承與實(shí)現(xiàn)繼承存在著不同。在公共繼承體系下，派生類總是繼承基類的接口。
l 純虛函數(shù)要求派生類僅繼承接口。
l 簡單（非純）虛函數(shù)要求派生類在繼承接口的同時(shí)繼承一個(gè)默認(rèn)的實(shí)現(xiàn)。
l 非虛函數(shù)要求派生類繼承接口和強(qiáng)制固定內(nèi)容的實(shí)現(xiàn)。