條目32中我們討論過：C++將公共繼承處理為“A是一個B”關(guān)系。比如我們給定一個Student類繼承自Person類的層次結(jié)構(gòu)，那么編譯器則會在特定的時刻將Student對象隱式的轉(zhuǎn)變?yōu)?span style="font-family:"Courier New";">Person對象，以便使特定的函數(shù)得以成功調(diào)用，這一點(diǎn)C++本身已經(jīng)為我們考慮周全了。這里我們不妨繼續(xù)花一點(diǎn)時間研究一下，在上述示例中如果使用私有繼承代替公共繼承會發(fā)生什么：

很明顯，私有繼承并不呈現(xiàn)“A是一個B”的關(guān)系。那么私有繼承表示的是什么關(guān)系呢？

“哇。。。”你說，“在我們討論私有繼承的含義之前，讓我們先了解一下它的行為，私有繼承擁有怎樣的行為呢？”好的，正如上文的代碼中我們看到的，私有繼承的第一條守則是：如果類之間的層次關(guān)系是私有繼承的話，那么編譯器一般不會將派生類對象（比如Student）直接轉(zhuǎn)換為一個基類對象（比如Person）。這一點(diǎn)是與公共繼承背道而馳的。這也就說明了為什么對s對象調(diào)用eat函數(shù)時會發(fā)生錯誤。第二條守則是：派生類中繼承自私有基類的成員也將成為私有成員，即使他們在基類中用public或protected修飾也是如此。

行為就介紹到這。下面我們來討論含義。私有繼承意味著“A以B的形式實(shí)現(xiàn)”。如果有人編寫了一個D類私有繼承自B類，那么他這樣做的真實(shí)目的應(yīng)該是想借用B類中某些功能或特征，而不是B和D之間在概念層面的什么關(guān)系。綜上，我們說私有繼承是一個純粹的實(shí)現(xiàn)域的技術(shù)。（也就是為什么在派生類中繼承自私有基類的一切都是私有的：這一切都是具體實(shí)現(xiàn)的細(xì)節(jié)）私有繼承（條目34中引入的概念）意味著只有實(shí)現(xiàn)應(yīng)該被繼承下來，而接口則應(yīng)該忽略掉。如果D私有繼承自B，那么這就意味著D對象以B對象的形式實(shí)現(xiàn)，而且再沒有其他任何意義。私有繼承只存在于軟件實(shí)現(xiàn)的過程中，而在軟件設(shè)計過程中永遠(yuǎn)不會涉及。

私有繼承意味著“A以B的形式實(shí)現(xiàn)”的關(guān)系，這一事實(shí)顯得有些令人困惑，因?yàn)闂l目38中指出，組合可以做同樣的事情。那么在這兩者中要怎樣做出權(quán)衡取舍呢？答案很簡單：盡量使用組合，在不得已時才使用私有繼承。那么什么時候才是“不得已”的情形？主要是設(shè)計中出現(xiàn)了受保護(hù)的成員和/或虛函數(shù)的情形，這里還存在一種邊緣情形，當(dāng)存在存儲空間問題的情形下，我們還需要考慮更多。這個問題我們稍后再討論，畢竟它僅僅存在于極端條件下。

現(xiàn)在我們來考慮一個應(yīng)用程序，其中包含Widget對象。我們的設(shè)計要求我們對Widget的使用方式有一個更全面的了解。比如說，我們不僅僅需要了解諸如“Widget的成員函數(shù)多久會被調(diào)用”這類問題，還需要知道“調(diào)用的頻率隨時間的推移有何變化”。對于擁有不同運(yùn)行階段的程序而言，在各階段都需要有相應(yīng)的行為配置與之配套。比如說，對于一個編譯器而言，解釋階段所運(yùn)行的函數(shù)，與優(yōu)化和代碼生成階段的函數(shù)是大相徑庭的。

我們決定修改Widget類以便跟蹤每個成員函數(shù)被調(diào)用的次數(shù)。在運(yùn)行時，我們將不時檢查這一信息，這一工作可能與監(jiān)視每個Widget對象的值，以及其他一切我們認(rèn)為有用的數(shù)據(jù)同時進(jìn)行。為了達(dá)到這一目的，我們需要設(shè)置一個某種類型的計時器，以便讓我們掌握收集統(tǒng)計信息的時機(jī)。

復(fù)用現(xiàn)有代碼肯定比重寫新的代碼更好，因此我們“翻箱倒柜”尋找出了最適合的類，下邊是代碼：

這正是我們需要的。對于Timer對象，我們可以依照需要任意設(shè)定表針跳動的頻率，而且對于每一次跳動，該對象都會自動調(diào)用一個虛函數(shù)。我們可以對這一虛函數(shù)進(jìn)行重定義，以使它具備監(jiān)視所有Widget對象當(dāng)前狀態(tài)的功能。堪稱完美！

為了讓Widget重定義Timer重的虛函數(shù)，Widget必須繼承自Timer。但是公共繼承在此時就不合時宜了。我們不能說“Widget是一個Timer”。由于onTick不是Widget概念層面接口的一部分，因此Widget的客戶不應(yīng)該擁有調(diào)用onTick的權(quán)限。如果我們讓客戶能夠調(diào)用這類函數(shù)的話，那么他們很容易就會用錯Widget的接口。這顯然違背了條目18目中的建議：“讓接口更易使用，而不易被誤用”。公共繼承在這里并不是一個可選方案。

于是我們使用私有繼承：

借助于私有繼承的美妙特性，Timer類的公共函數(shù)onTick在Widget中變成了私有的，同時我們確保onTick在Widget中被重定義。再次強(qiáng)調(diào)，將onTick置于公共接口下將會使客戶誤認(rèn)為這些函數(shù)可以調(diào)用，這將會違背條目18目。

這是一個不錯的設(shè)計方案，但是這里使用私有繼承并不是必須的，這樣做并沒有實(shí)際的意義。如果我們使用組合來代替也沒有問題。我們可以在Widget類的內(nèi)部聲明一個私有的嵌套類，并由這個嵌套類公共繼承Timer，在此嵌套類中重定義onTick，然后在Widget類中放置一個改嵌套類的對象。以下代碼是這一方法的概要：

這一設(shè)計比僅使用私有繼承的版本更加復(fù)雜，這是因?yàn)榇嗽O(shè)計中包含了公共繼承和組合兩種技術(shù)，并且引入了一個新的類（WidgetTimer）。坦白說，我介紹這一方案的主要目的實(shí)際上是要告訴大家設(shè)計不要局限于某種單一的方案，刻意訓(xùn)練自己對于同一個問題舉一反三，會令你受益非淺（參見條目35）。最后，我還是要舉出兩個理由來說明：公共繼承加組合的方案要優(yōu)于私有繼承。

首先，你可能期望將Widget設(shè)計為可派生的類，但是同時你也希望在派生類中阻止對onTick的重定義。如果Widget繼承自Timer，那么即便你使用私有繼承，你的期望也無法完全達(dá)成。（請回憶條目35：盡管派生類中無法調(diào)用基類中的虛函數(shù)，派生類中也可以對虛函數(shù)做出重定義。）但是，如果由WidgetTimer繼承自Timer，并將其放置在Widget中作為私有嵌套類，這樣Widget的派生類便失去了對WidgetTimer的訪問權(quán)限，于是Widget的派生類則無法繼承WidgetTimer，也無法重定義WidgetTimer內(nèi)的虛函數(shù)。如果你曾經(jīng)使用Java或C#編程，你會發(fā)現(xiàn)這兩種語言中沒有防止派生類重定義虛函數(shù)（Java中的final方法，C#中的sealed方法）的功能，現(xiàn)在你已經(jīng)了解如何在C++中等效的實(shí)現(xiàn)這一行為。

其次，你可能期望使Widget的編譯依賴程度最小化。如果Widget繼承自Timer，那么在編譯Widget類時，Timer必須有可用的定義，因此定義Widget類的文件可能需要添加 #include ”Timer.h” 指令。另外，如果將WidgetTimer移出Widget， Widget中僅包含一個指向WidgetTimer的指針，Widget可以通過WidgetTimer類的簡單聲明來調(diào)用這一指針。這樣不需要任何 #include 指令就可以使用Timer。對于大型系統(tǒng)來說，這樣的剝離工作可能是非常重要的。（對于最小化編譯依賴議題，請參見條目31）

上文曾強(qiáng)調(diào)過，私有繼承主要應(yīng)用于以下情形：一個“準(zhǔn)派生類”需要訪問“準(zhǔn)基類”中受保護(hù)的部分，或者需要重定義一個或多個虛函數(shù)，但是兩個類之間在概念層面的關(guān)系是“A以B的形式實(shí)現(xiàn)”，而不是“A是一個B”。然而，我們也說過，當(dāng)涉及到空間優(yōu)化問題時，這里存在一種邊緣情形，我們更傾向于使用虛擬繼承，而不是組合。

此邊緣情形中的“邊緣”實(shí)際上是十分“鋒利”的，也就是說它發(fā)生的幾率很小：只有在你使用一個不存在數(shù)據(jù)的類時才會遇到。這樣的類中，沒有非靜態(tài)數(shù)據(jù)成員，沒有虛函數(shù)（因?yàn)樘摵瘮?shù)的存在會使每一個對象中添加一個vptr，參見條目7），沒有虛擬基類（因?yàn)樘摂M基類會帶來一個size的開銷，參見條目40）。在概念層面，這些空類的對象不應(yīng)該使用任何空間，因?yàn)閷γ總€對象而言，是沒有任何數(shù)據(jù)需要存儲的。然而，C++強(qiáng)制要求這些獨(dú)立的對象不得不占據(jù)任何空間，是有其技術(shù)上的原因的。比如你寫下了下面的代碼：

你將發(fā)現(xiàn)：sizeof(HoldsAnInt) > sizeof(int)。Empty數(shù)據(jù)成員也需要內(nèi)存。對于大多數(shù)編譯器而言，sizeof(Empty)的值是1，這是因?yàn)镃++中禁止存在零空間的獨(dú)立對象，這一“禁令”一般是靜默地通過在“空”對象中添加一個char成員來達(dá)成的。然而，C++對內(nèi)存對齊的要求會使得編譯器在諸如HoldsAnInt這樣的類中做適當(dāng)?shù)奶畛洌虼?span style="font-family:"Courier New";">HoldsAnInt對象中很可能不僅添加了一個char的空間，這些對象可能被擴(kuò)容到能容納另一個int。（我所測試的所有編譯器都恰好是這樣的情形）

但是你可能注意到剛才的討論我很小心的使用了一個字眼——“獨(dú)立”，這類對象不能為零空間。對于擁有派生類對象的基類就沒有強(qiáng)制約束了，這是因?yàn)檫@類對象不是獨(dú)立的。如果Empty不是包含于HoldsAnInt中，而是被其繼承：

你一定會發(fā)現(xiàn)，sizeof(HoldsAnInt) == sizeof(int)。這一情形被稱為“空基類優(yōu)化（empty base optimization，簡稱EBO）”，我所測試的所有編譯器均支持這一特性。如果你是一個類庫開發(fā)人員，你的客戶更關(guān)心內(nèi)存空間問題，那么EBO則很值得你去了解。同時還有一件事，EBO一般只在單一層次環(huán)境中可行。一般情況下，C++對象的排列守則要求EBO不能適用于繼承自多個基類的派生類。

在實(shí)際環(huán)境中，盡管“空”類中不包含任何非靜態(tài)數(shù)據(jù)成員，但實(shí)際上它們并不真是空的。這些空類中通常會包含typedef、枚舉類型成員、靜態(tài)數(shù)據(jù)成員，或非虛函數(shù)。STL中包含很多技術(shù)層面的空類，這些類包含了諸多有用的成員（通常是typedef），包括unary_function和binary_function這些基類，一般一些用戶自定義的函數(shù)對象可以繼承它們。感謝EBO的廣泛應(yīng)用，這樣的繼承操作一般不會為派生類帶來額外的空間開銷。

讓我們重溫基礎(chǔ)的部分。大多數(shù)類不是空的，因此僅在極少數(shù)情況下，EBO可以作為私有繼承的合理理由。另外，大多數(shù)繼承結(jié)構(gòu)呈現(xiàn)出“A是一個B”關(guān)系，其應(yīng)由公共繼承司職，而不是私有繼承。組合和私有繼承都意味著“A以B的形式實(shí)現(xiàn)”關(guān)系，但是組合更易于理解，因此你應(yīng)該盡可能的使用它。

當(dāng)你正在處理的兩個類沒有呈現(xiàn)“A是一個B”關(guān)系，并且其中一個類需要訪問另一個類中的受保護(hù)的成員，或者需要重定義其中一個或若干個虛函數(shù)的情況下，私有繼承最有可能成為一個合理的設(shè)計策略。即使在這種情況下，我們看到配合使用公共繼承和組合的方法可以得到等效的行為，只是在設(shè)計上略顯復(fù)雜。當(dāng)你需要描述這樣的兩個類之間的關(guān)系時，使用私有繼承要三思而后行。這意味著在你考慮過其他所有的可行方案后，并且確定沒有比它更合適的，才選擇使用。

時刻牢記

l 私有繼承意味著“A以B的形式實(shí)現(xiàn)”。通常它的優(yōu)先級要低于組合，但是當(dāng)派生類需要訪問基類中受保護(hù)的成員，或者需要重定義派生的虛函數(shù)時，私有繼承還是有其存在的合理性的。

l 與組合不同，私有繼承可以啟用“空基類優(yōu)化”特性。對于類庫開發(fā)人員而言，私有繼承對于降低對象尺寸來說至關(guān)重要。