條目32中我們討論過：C++將公共繼承處理為“A是一個B”關系。比如我們給定一個Student類繼承自Person類的層次結構，那么編譯器則會在特定的時刻將Student對象隱式的轉變為Person對象，以便使特定的函數得以成功調用，這一點C++本身已經為我們考慮周全了。這里我們不妨繼續花一點時間研究一下，在上述示例中如果使用私有繼承代替公共繼承會發生什么：
class Person { ... };
class Student: private Person { ... };
// 現在是私有繼承
void eat(const Person& p); // 每個人都能吃東西
void study(const Student& s); // 只有學生會學習
Person p; // p是Person對象
Student s; // s是Student對象
eat(p); // 正確，p是Person對象
eat(s); // 錯誤！Student對象
// 不是Person對象
很明顯，私有繼承并不呈現“A是一個B”的關系。那么私有繼承表示的是什么關系呢？
“哇。。。”你說，“在我們討論私有繼承的含義之前，讓我們先了解一下它的行為，私有繼承擁有怎樣的行為呢？”好的，正如上文的代碼中我們看到的，私有繼承的第一條守則是：如果類之間的層次關系是私有繼承的話，那么編譯器一般不會將派生類對象（比如Student）直接轉換為一個基類對象（比如Person）。這一點是與公共繼承背道而馳的。這也就說明了為什么對s對象調用eat函數時會發生錯誤。第二條守則是：派生類中繼承自私有基類的成員也將成為私有成員，即使他們在基類中用public或protected修飾也是如此。
行為就介紹到這。下面我們來討論含義。私有繼承意味著“A以B的形式實現”。如果有人編寫了一個D類私有繼承自B類，那么他這樣做的真實目的應該是想借用B類中某些功能或特征，而不是B和D之間在概念層面的什么關系。綜上，我們說私有繼承是一個純粹的實現域的技術。（也就是為什么在派生類中繼承自私有基類的一切都是私有的：這一切都是具體實現的細節）私有繼承（條目34中引入的概念）意味著只有實現應該被繼承下來，而接口則應該忽略掉。如果D私有繼承自B，那么這就意味著D對象以B對象的形式實現，而且再沒有其他任何意義。私有繼承只存在于軟件實現的過程中，而在軟件設計過程中永遠不會涉及。
私有繼承意味著“A以B的形式實現”的關系，這一事實顯得有些令人困惑，因為條目38中指出，組合可以做同樣的事情。那么在這兩者中要怎樣做出權衡取舍呢？答案很簡單：盡量使用組合，在不得已時才使用私有繼承。那么什么時候才是“不得已”的情形？主要是設計中出現了受保護的成員和/或虛函數的情形，這里還存在一種邊緣情形，當存在存儲空間問題的情形下，我們還需要考慮更多。這個問題我們稍后再討論，畢竟它僅僅存在于極端條件下。
現在我們來考慮一個應用程序，其中包含Widget對象。我們的設計要求我們對Widget的使用方式有一個更全面的了解。比如說，我們不僅僅需要了解諸如“Widget的成員函數多久會被調用”這類問題，還需要知道“調用的頻率隨時間的推移有何變化”。對于擁有不同運行階段的程序而言，在各階段都需要有相應的行為配置與之配套。比如說，對于一個編譯器而言，解釋階段所運行的函數，與優化和代碼生成階段的函數是大相徑庭的。
我們決定修改Widget類以便跟蹤每個成員函數被調用的次數。在運行時，我們將不時檢查這一信息，這一工作可能與監視每個Widget對象的值，以及其他一切我們認為有用的數據同時進行。為了達到這一目的，我們需要設置一個某種類型的計時器，以便讓我們掌握收集統計信息的時機。
復用現有代碼肯定比重寫新的代碼更好，因此我們“翻箱倒柜”尋找出了最適合的類，下邊是代碼：
class Timer {
public:
explicit Timer(int tickFrequency);
virtual void onTick() const; // 表針跳一下，自動調用一回
...
};
這正是我們需要的。對于Timer對象，我們可以依照需要任意設定表針跳動的頻率，而且對于每一次跳動，該對象都會自動調用一個虛函數。我們可以對這一虛函數進行重定義，以使它具備監視所有Widget對象當前狀態的功能。堪稱完美！
為了讓Widget重定義Timer重的虛函數，Widget必須繼承自Timer。但是公共繼承在此時就不合時宜了。我們不能說“Widget是一個Timer”。由于onTick不是Widget概念層面接口的一部分，因此Widget的客戶不應該擁有調用onTick的權限。如果我們讓客戶能夠調用這類函數的話，那么他們很容易就會用錯Widget的接口。這顯然違背了條目18目中的建議：“讓接口更易使用，而不易被誤用”。公共繼承在這里并不是一個可選方案。
于是我們使用私有繼承：
class Widget: private Timer {
private:
virtual void onTick() const; // 監視Widget對象的使用數據等等
...
};
借助于私有繼承的美妙特性，Timer類的公共函數onTick在Widget中變成了私有的，同時我們確保onTick在Widget中被重定義。再次強調，將onTick置于公共接口下將會使客戶誤認為這些函數可以調用，這將會違背條目18目。
這是一個不錯的設計方案，但是這里使用私有繼承并不是必須的，這樣做并沒有實際的意義。如果我們使用組合來代替也沒有問題。我們可以在Widget類的內部聲明一個私有的嵌套類，并由這個嵌套類公共繼承Timer，在此嵌套類中重定義onTick，然后在Widget類中放置一個改嵌套類的對象。以下代碼是這一方法的概要：
class Widget {
private:
class WidgetTimer: public Timer {
public:
virtual void onTick() const;
...
};
WidgetTimer timer;
...
};
這一設計比僅使用私有繼承的版本更加復雜，這是因為此設計中包含了公共繼承和組合兩種技術，并且引入了一個新的類（WidgetTimer）。坦白說，我介紹這一方案的主要目的實際上是要告訴大家設計不要局限于某種單一的方案，刻意訓練自己對于同一個問題舉一反三，會令你受益非淺（參見條目35）。最后，我還是要舉出兩個理由來說明：公共繼承加組合的方案要優于私有繼承。
首先，你可能期望將Widget設計為可派生的類，但是同時你也希望在派生類中阻止對onTick的重定義。如果Widget繼承自Timer，那么即便你使用私有繼承，你的期望也無法完全達成。（請回憶條目35：盡管派生類中無法調用基類中的虛函數，派生類中也可以對虛函數做出重定義。）但是，如果由WidgetTimer繼承自Timer，并將其放置在Widget中作為私有嵌套類，這樣Widget的派生類便失去了對WidgetTimer的訪問權限，于是Widget的派生類則無法繼承WidgetTimer，也無法重定義WidgetTimer內的虛函數。如果你曾經使用Java或C#編程，你會發現這兩種語言中沒有防止派生類重定義虛函數（Java中的final方法，C#中的sealed方法）的功能，現在你已經了解如何在C++中等效的實現這一行為。
其次，你可能期望使Widget的編譯依賴程度最小化。如果Widget繼承自Timer，那么在編譯Widget類時，Timer必須有可用的定義，因此定義Widget類的文件可能需要添加 #include ”Timer.h” 指令。另外，如果將WidgetTimer移出Widget， Widget中僅包含一個指向WidgetTimer的指針，Widget可以通過WidgetTimer類的簡單聲明來調用這一指針。這樣不需要任何 #include 指令就可以使用Timer。對于大型系統來說，這樣的剝離工作可能是非常重要的。（對于最小化編譯依賴議題，請參見條目31）
上文曾強調過，私有繼承主要應用于以下情形：一個“準派生類”需要訪問“準基類”中受保護的部分，或者需要重定義一個或多個虛函數，但是兩個類之間在概念層面的關系是“A以B的形式實現”，而不是“A是一個B”。然而，我們也說過，當涉及到空間優化問題時，這里存在一種邊緣情形，我們更傾向于使用虛擬繼承，而不是組合。
此邊緣情形中的“邊緣”實際上是十分“鋒利”的，也就是說它發生的幾率很小：只有在你使用一個不存在數據的類時才會遇到。這樣的類中，沒有非靜態數據成員，沒有虛函數（因為虛函數的存在會使每一個對象中添加一個vptr，參見條目7），沒有虛擬基類（因為虛擬基類會帶來一個size的開銷，參見條目40）。在概念層面，這些空類的對象不應該使用任何空間，因為對每個對象而言，是沒有任何數據需要存儲的。然而，C++強制要求這些獨立的對象不得不占據任何空間，是有其技術上的原因的。比如你寫下了下面的代碼：
class Empty {}; // 由于沒有任何數據，
// 因此對象也應不占任何內存
class HoldsAnInt { // 應僅占一個int的空間
private:
int x;
Empty e; // 不應消耗任何內存
};
你將發現：sizeof(HoldsAnInt) > sizeof(int)。Empty數據成員也需要內存。對于大多數編譯器而言，sizeof(Empty)的值是1，這是因為C++中禁止存在零空間的獨立對象，這一“禁令”一般是靜默地通過在“空”對象中添加一個char成員來達成的。然而，C++對內存對齊的要求會使得編譯器在諸如HoldsAnInt這樣的類中做適當的填充，因此HoldsAnInt對象中很可能不僅添加了一個char的空間，這些對象可能被擴容到能容納另一個int。（我所測試的所有編譯器都恰好是這樣的情形）
但是你可能注意到剛才的討論我很小心的使用了一個字眼——“獨立”，這類對象不能為零空間。對于擁有派生類對象的基類就沒有強制約束了，這是因為這類對象不是獨立的。如果Empty不是包含于HoldsAnInt中，而是被其繼承：
class HoldsAnInt: private Empty {
private:
int x;
};
你一定會發現，sizeof(HoldsAnInt) == sizeof(int)。這一情形被稱為“空基類優化（empty base optimization，簡稱EBO）”，我所測試的所有編譯器均支持這一特性。如果你是一個類庫開發人員，你的客戶更關心內存空間問題，那么EBO則很值得你去了解。同時還有一件事，EBO一般只在單一層次環境中可行。一般情況下，C++對象的排列守則要求EBO不能適用于繼承自多個基類的派生類。
在實際環境中，盡管“空”類中不包含任何非靜態數據成員，但實際上它們并不真是空的。這些空類中通常會包含typedef、枚舉類型成員、靜態數據成員，或非虛函數。STL中包含很多技術層面的空類，這些類包含了諸多有用的成員（通常是typedef），包括unary_function和binary_function這些基類，一般一些用戶自定義的函數對象可以繼承它們。感謝EBO的廣泛應用，這樣的繼承操作一般不會為派生類帶來額外的空間開銷。
讓我們重溫基礎的部分。大多數類不是空的，因此僅在極少數情況下，EBO可以作為私有繼承的合理理由。另外，大多數繼承結構呈現出“A是一個B”關系，其應由公共繼承司職，而不是私有繼承。組合和私有繼承都意味著“A以B的形式實現”關系，但是組合更易于理解，因此你應該盡可能的使用它。
當你正在處理的兩個類沒有呈現“A是一個B”關系，并且其中一個類需要訪問另一個類中的受保護的成員，或者需要重定義其中一個或若干個虛函數的情況下，私有繼承最有可能成為一個合理的設計策略。即使在這種情況下，我們看到配合使用公共繼承和組合的方法可以得到等效的行為，只是在設計上略顯復雜。當你需要描述這樣的兩個類之間的關系時，使用私有繼承要三思而后行。這意味著在你考慮過其他所有的可行方案后，并且確定沒有比它更合適的，才選擇使用。
時刻牢記
l 私有繼承意味著“A以B的形式實現”。通常它的優先級要低于組合，但是當派生類需要訪問基類中受保護的成員，或者需要重定義派生的虛函數時，私有繼承還是有其存在的合理性的。
l 與組合不同，私有繼承可以啟用“空基類優化”特性。對于類庫開發人員而言，私有繼承對于降低對象尺寸來說至關重要。