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