走出 Abstract Class 與 Interface 選型困惑：從語法到設計哲學的深度剖析

抽象類的本質

抽象類表達「一組固定行為的抽象描述，擁有任意多種具體實現」。它是面向對象設計核心原則 **OCP（開閉原則）** 的關鍵：模塊依賴抽象不變，通過繼承擴展行為。

語法層面差異

默認實現的維護價值

• 接口新增方法 → 所有實現類**必須修改** → 災難性擴散
• 抽象類新增方法 + 默認實現 → 僅修改基類 → 受控變更
• 避免「相同邏輯散落在每個子類」違反「一處變更、一條規則」原則

設計哲學層面：Door + Alarm 經典案例

需求演進

1. 基礎：Door 有 open()、close()
2. 新增：部分需 alarm() 報警功能

方案一：單一介面/抽象類塞入 alarm()

interface Door { void open(); void close(); void alarm(); }

❌ 違反 **ISP（介面隔離原則）**：將「門」與「報警器」兩個概念強行合一。依賴 Door 的模塊會因 Alarm 變更而受影響，反之亦然。

方案二：拆分為兩個概念

Java 不支持多重繼承，故兩個抽象類不可行。可行組合：

推薦實現

abstract class Door {
    abstract void open();
    abstract void close();
}

interface Alarm {
    void alarm();
}

class AlarmDoor extends Door implements Alarm {
    void open() { ... }
    void close() { ... }
    void alarm() { ... }
}

選型決策樹

1. 是否需要默認實現？ → 是 → abstract class
2. 是否表達核心領域「is-a」關係？ → 是 → abstract class
3. 是否定義橫切能力/契約（like-a）？ → 是 → interface
4. 需要多重組合？ → interface
5. 既要 is-a 又要 like-a？ → abstract class 主線 + interface 能力

結語

選擇 abstract class 還是 interface，**不僅是語法偏好，更是領域模型理解的體現**。abstract class 定義「是什麼」，interface 定義「能做什麼」。正確選型讓代碼語言化設計意圖，降低認知負荷，支撐長期演化。