C++ 繼承機制的局限性：別讓「是一種」關係誤導設計

前言

「封裝、繼承、多態」常被稱為面向物件三大特性，但這實際上是 **C++ 對 C 的擴充特性**，而非面向物件思想的本質 (核心是「世界由物件構成」)。本文探討 C++ 繼承機制的內在局限，避免濫用導致設計僵化。

經典誤區：幾何圖形建模

許多教材用「四邊形 → 矩形 → 正方形」繼承鏈示範。直覺認為：

class Quadrangle { ... };
class Rectangle : public Quadrangle { ... };
class Square : public Rectangle { ... };

**悖論**：繼承意味著 **派生類比基類更複雜** (增加新欄位/方法)。但從四邊形到正方形，**約束越來越多、資料越來越少** (四邊形需 4 邊長、矩形需寬高、正方形只需邊長)。繼承方向與複雜度演進 **背道而馳**。

無場景不設計

「在沒有給定需求場景的情況下，永遠無法設計出一個類，更別說類之間的層次關係。」
若需求僅為「取邊長、算面積」，三個類應 **獨立實作**，各自最優化：

class Quadrangle { int GetSide(int idx); int Area(); int sides[4]; };
class Rectangle  { int Width(); int Height(); int Area(); int w, h; };
class Square     { int Width(); int Area(); int w; };

若必須表達層次關係：用介面

繼承機制 (Implementation Inheritance) 與 **介面機制** (Interface Inheritance) 是兩碼子事。C++ 用純虛擬類別模擬介面：

class IShape { virtual int Area() = 0; virtual ~IShape() {} };
class Quadrangle : public IShape { ... };
class Rectangle  : public IShape { ... };
class Square     : public IShape { ... };

→ **介面描述「是什麼」 (分類學)；實作繼承描述「如何實作」 (程式碼復用)。勿混淆。**

繼承的核心局限

1. 難以對應現實概念的分類學層次 (如生物演化樹、幾何圖形)。
2. 強耦合：派生類依賴基類實作細節，基類變更波及所有派生類。
3. 脆弱基類問題：基類修改易破壞派生類不變條件。

濫用繼承做程式碼復用的反例：MFC/WTL 視窗與控制項

視窗與控制項本質不同，微軟為復用訊息機制強行讓所有控制項繼承 CWnd，導致：

• 控制項背負視窗的所有複雜性 (訊息映射、DC 管理、父子關係...)。
• 難以擴展新控制項類型 (如無視窗控制項、DirectComposition 節點)。
• 高複雜度、高耦合、難測試。

教訓：程式碼復用是良好設計的**副產品**，而非設計目的。**

實戰原則

1. 優先組合 (Composition) / 聚合 (Aggregation)：has-a 比 is-a 更靈活、耦合更低。
2. 介面隔離：定義純虛擬介面表達行為契約，具體類別實作介面。
3. 僅在真正的「是一種」且「派生類擴充基類行為」時使用繼承 (如 std::vector → MyVector 加入邊界檢查)。
4. 避免深層繼承鏈：超過 2-3 層通常是設計腐壞訊號。

總結

1. 繼承機制有嚴重局限，難描述現實分類層次。
2. 別生搬硬套現實「是一種」關係進繼承體系。
3. 純為程式碼復用而繼承是反模式，優先用組合/介面。
4. 介面 ≠ 繼承，C++ 用純虛類別實作介面，但兩者本質不同。