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