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

前言：三大特徵其實是 C++ 對 C 的擴充，非 OO 本質

封裝、繼承、多態常被稱為「面向物件三大特徵」。但 OO 本質是「世界由物件構成」，與面向過程的世界觀不同。三大特徵實際上是 C++ 相對於 C 的三大語法擴充，甚至在編譯器層面只是「語法糖」。理解這點，有助於我們擺脫教條，回歸設計本質。

經典陷阱：幾何圖形的繼承建模

教科書常用「四邊形 → 矩形 → 正方形」繼承鏈建模。新手直覺認為合理，資深工程師卻敏銳發現悖論：

• 繼承特性：子類別比父類別更複雜（繼承父類實作並新增成員/方法）。
• 幾何現實：四邊形（4 邊長） → 矩形（寬/高） → 正方形（邊長），複雜度遞減。
• 結果：無法用繼承自然表達此層次關係。

無需求場景，不做類別設計

若無具體功能需求（如「取邊長」「計算面積」），直接設計 Student、Teacher 類別毫無意義。類別設計必須服務於具體行為契約。

三種實作方案對比

方案一：各自獨立實作（推薦大多數場景）

class Quadrangle {  // 四邊形
    int GetSideLength(int index);
    int GetArea();
    int m_sides[4];
};
class Rectangle {   // 矩形
    int GetWidth(); int GetHeight(); int GetArea();
    int m_width, m_height;
};
class Square {      // 正方形
    int GetWidth(); int GetArea();
    int m_width;
};

各類別獨立，無繼承關係。簡單、直接、符合開閉原則。

方案二：介面描述層次，類別獨立實作

若必須表達概念層次，引入純虛類別（介面）：

class IShape {          // 介面
    virtual int GetArea() = 0;
};
class Quadrangle : public IShape { ... };
class Rectangle  : public IShape { ... };
class Square     : public IShape { ... };

關鍵洞見：C++ 用純虛類別實作介面，但介面機制 ≠ 繼承機制。介面描述「契約/層次」，繼承用於「實作復用/擴充」，兩者本質不同。

方案三：強行繼承（反面教材）

class Quadrangle { ... };
class Rectangle : public Quadrangle { ... };  // 強行加欄位、改行為
class Square : public Rectangle { ... };      // 更糟：正方形不是矩形的特化（寬高可獨立變化）

導致：Square 繼承了 Rectangle 的 SetWidth/SetHeight，違反里氏替換原則（LSP），引發執行期錯誤或需大量防禦性程式碼。

繼承的核心局限性

1. 難以描述現實概念層次：現實分類常為「組合/約束」關係，非單純「是一種」。
2. 易被濫用於程式碼復用：如 MFC/WTL 中視窗與控制項強行繼承，導致框架高複雜度、難擴展。程式碼復用應是良好設計的副產品，而非設計目的。
3. 緊耦合、脆弱基類別問題：父類別變更波及所有子類別，維護成本高。

設計原則總結

1. 優先用組合/介面：表達領域概念層次用介面，行為復用用組合/委派。
2. 謹慎使用繼承：僅當「子類別確實是父類別的特化、且需擴充父類實作」時使用。
3. 避免生搬硬套現實分類：嘗試用繼承描述演化樹，你會發現根本行不通。
4. 設計目標是低耦合、高內聚，而非最大化程式碼復用率。

微博：@飛舞的煙灰缸