條款32：確定你的public繼承塑模出is-a關系 Make sure public inheritance models"is-a."
如果你令class D（"Derived"）以public形式繼承class B（"Base"），你便是告訴C++編譯器（以及你的代碼讀者）說，每一個類型為 D的對象同時也是一個類型為B的對象，反之不成立。
你的意思是B比D表現出更一般化的概念，而D比B表現出更特殊化的概念。
is-a并非是唯一存在于classes之間的關系。另兩個常見的關系是has-a（有一個）和is-implemented-in-terms-of（根據某物實現出）。這些關系將在條款38和39討論。將上述這些重要的相互關系中的任何一個誤塑為is-a而造成的錯誤設計，在C++中并不罕見，所以你應該確定你確實了解這些個“classes 相互關系”之間的差異，并知道如何在C++中最好地塑造它們。
請記住
■ “public繼承”意味is-a。適用于base classes身上的每一件事情一定也適用于derived classes身上，因為每一個derived class對象也都是一個base class對象。
條款33：避免遮掩繼承而來的名稱 Avoid hiding inherited names.
請記住
■ derived classes內的名稱會遮掩base classes內的名稱。在public繼承下從來沒有人希望如此。
■ 為了讓被遮掩的名稱再見天日，可使用 using 聲明式或轉交函數（forwarding functions）。
條款34：區分接口繼承和實現繼承 Differentiate between inheritance of interface and inheritance of implementation.
表面上直截了當的public繼承概念，經過更嚴密的檢查之后，發現它由兩部分組成：函數接口（function interfaces）繼承和函數實現（functionimplementations）繼承。這兩種繼承的差異，很像本書導讀所討論的函數聲明與函數定義之間的差異。
請記住
■ 接口繼承和實現繼承不同。在public繼承之下，derived classes總是繼承baseclass的接口。
■ pure virtual函數只具體指定接口繼承。
■ 簡樸的（非純）impure virtual函數具體指定接口繼承及缺省實現繼承。
■ non-virtual函數具體指定接口繼承以及強制性實現繼承。
條款35：考慮virtual函數以外的其他選擇 Consider alternatives to virtual functions.
摘要本條款的根本忠告是，當你為解決問題而尋找某個設計方法時，不妨考慮virtual函數的替代方案。
下面快速重點復習我們驗證過的幾個替代方案：
■ 使用non-virtual interface（NVI）手法，那是Template Method設計模式的一種特殊形式。它以public non-virtual成員函數包裹較低訪問性（private或protected）的virtual函數。
■ 將virtual函數替換為“函數指針成員變量”，這是Strategy設計模式的一種分解表現形式。
■ 以 tr1：：function 成員變量替換 virtual 函數，因而允許使用任何可調用物（callable entity）搭配一個兼容于需求的簽名式。這也是 Strategy設計模式的某種形式。
■ 將繼承體系內的 virtual 函數替換為另一個繼承體系內的 virtual 函數。這是Strategy設計模式的傳統實現手法。
以上并未徹底而詳盡地列出virtual函數的所有替換方案，但應該足夠讓你知道的確有不少替換方案。此外，它們各有其相對的優點和缺點，你應該把它們全部列入考慮。為避免陷入面向對象設計路上因常規而形成的凹洞中，偶而我們需要對著車輪猛推一把。這個世界還有其他許多道路，值得我們花時間加以研究。
請記住
■ virtual函數的替代方案包括NVI手法及Strategy設計模式的多種形式。NVI手法自身是一個特殊形式的Template Method設計模式。
■ 將機能從成員函數移到class外部函數，帶來的一個缺點是，非成員函數無法訪問class的non-public成員。
■ tr1：：function 對象的行為就像一般函數指針。這樣的對象可接納“與給定之目標簽名式（target signature）兼容”的所有可調用物（callable entities）。
條款36：絕不重新定義繼承而來的non-virtual函數Never redefine an inherited non-virtual function.
請記住
■ 絕對不要重新定義繼承而來的non-virtual函數。
條款37：絕不重新定義繼承而來的缺省參數值 Never redefine a function's inherited default parameter value.
請記住
■ 絕對不要重新定義一個繼承而來的缺省參數值，因為缺省參數值都是靜態綁定，而virtual函數——你唯一應該覆寫的東西——卻是動態綁定。
條款38：通過復合塑模出has-a或“根據某物實現出”Model"has-a"or"is-implemented-in-terms-of"through composition.
請記住
■ 復合（composition）的意義和public繼承完全不同。
■ 在應用域（application domain），復合意味 has-a （有一個）。在實現域（implementation domain），復合意味is-implemented-in-terms-of（根據某物實現出）。
條款39：明智而審慎地使用private繼承 Use private inheritance judiciously.
請記住
■ Private繼承意味is-implemented-in-terms of（根據某物實現出）。它通常比復合（composition）的級別低。但是當derived class需要訪問protected base class的成員，或需要重新定義繼承而來的virtual函數時，這么設計是合理的。
■ 和復合（composition）不同，private繼承可以造成empty base最優化。這對致力于“對象尺寸最小化”的程序庫開發者而言，可能很重要。
條款40：明智而審慎地使用多重繼承 Use multiple inheritance judiciously.
請記住
■ 多重繼承比單一繼承復雜。它可能導致新的歧義性，以及對virtual繼承的需要。
■ virtual繼承會增加大小、速度、初始化（及賦值）復雜度等等成本。如果virtualbase classes不帶任何數據，將是最具實用價值的情況。
■ 多重繼承的確有正當用途。其中一個情節涉及“public繼承某個Interface class”和“private繼承某個協助實現的class”的兩相組合。
摘自《Effective C++：改善程序與設計的55個具體做法：第三版》
