Java 抽象類與介面深度對比：語法、設計哲學與選型決策指南

abstract class 與 interface 是 Java 支援抽象定義的兩大機制，二者相似卻本質不同。選型不當會導致架構僵化、擴展困難。本文從語法層面、設計哲學、演進歷程、實戰決策四個維度深度剖析。

一、語法層面核心差異 (JDK 8 為分水嶺)

二、設計哲學本質差異

抽象類：垂直維度的「模板化」

• 體現 泛化/特化 關係 (Generalization/Specialization)
• 父類定義骨架演算法 (Template Method)，子類填充變化點
• 共享狀態 (欄位) 與通用邏輯
• 必須滿足 Liskov 替換原則 (LSP)：子類型必須能替換父類型不破壞語義

介面：水平維度的「契約化」

• 體現 能力/契約 關係 (Capability/Contract)
• 定義行為規範，不關心實現細節與狀態
• 支援多重實現，一個類可實現多個介面 (如 Serializable、Comparable、Runnable)
• 介面隔離原則 (ISP)：介面越小越好，避免「胖介面」污染實現類

三、經典案例：Door 與 Alarm 重構演示

問題場景

Door 核心行為：open()、close()。新需求：增加報警功能 alarm()。

方案一：違反 ISP 的單一介面/抽象類

// 錯誤：將 Door 本質行為與 Alarm 獨立概念強耦合
interface Door {
    void open();
    void close();
    void alarm(); // 不屬於 Door 核心職責
}

後果：純門禁系統被迫實現 alarm()；報警邏輯變更波及所有門類型。

方案二：介面分離 + 組合 (推薦)

// 核心門契約
interface Door {
    void open();
    void close();
}

// 獨立報警契約
interface Alarm {
    void alarm();
}

// 具體實現：組合而非繼承
class AlarmDoor implements Door, Alarm {
    private final AlarmSystem alarmSystem; // 委派實現
    
    public void open() { /* 開門邏輯 */ }
    public void close() { /* 關門邏輯 */ }
    public void alarm() { alarmSystem.trigger(); }
}

// 普通門無需報警
class SimpleDoor implements Door {
    public void open() { /* ... */ }
    public void close() { /* ... */ }
}

方案三：抽象類提供預設實現 (適用於強 is-a 關係)

abstract class BaseDoor implements Door {
    // 共享狀態
    protected boolean locked = false;
    
    // 模板方法：核心流程固化
    public final void open() {
        if (locked) throw new IllegalStateException("Door locked");
        doOpen();
        onOpened();
    }
    
    protected abstract void doOpen(); // 子類實現具體開門方式
    protected void onOpened() {} // 鉤子方法
}

class SlidingDoor extends BaseDoor {
    protected void doOpen() { /* 滑動開門 */ }
}

class SwingDoor extends BaseDoor {
    protected void doOpen() { /* 旋轉開門 */ }
}

四、JDK 8+ 介面演進：模糊邊界與新選型策略

新增特性

• default 方法：介面提供預設實現，不破壞現有實現類
• static 方法：工具方法歸屬介面，如 Stream.of()
• private 方法 (JDK 9)：default 方法間共享邏輯

選型決策樹 (現代版)

1. 是否需要構造器/實例狀態？→ abstract class
2. 是否為強 "is-a" 關係且需共享非最終邏輯？→ abstract class (Template Method)
3. 是否為能力契約、需多實現、跨領域復用？→ interface
4. 需提供預設實現且不想強制繼承？→ interface + default
5. SPI 擴展點？→ interface (配合 ServiceLoader)

組合優於繼承原則

// 組合方式實現 AlarmDoor (優於繼承 AlarmDoorBase)
class AlarmDoor implements Door {
    private final Door delegate; // 基礎門功能
    private final Alarm alarm;   // 報警功能
    
    public AlarmDoor(Door delegate, Alarm alarm) {
        this.delegate = delegate;
        this.alarm = alarm;
    }
    
    public void open() { delegate.open(); }
    public void close() { delegate.close(); }
    public void alarm() { alarm.alarm(); }
}

優勢：運行時動態組合、單一職責、易測試、避免繼承層級爆炸。

五、總結：選型核心原則

抽象類定義「它是什麼」，介面定義「它能做什麼」。

• 優先使用 介面 定義類型契約，配合 default 提供演進兼容性
• 僅在需要共享狀態、強制模板流程、構造器初始化時使用抽象類
• 實現類通過 組合 裝配多種能力，而非繼承層級疊加
• 架構邊界 (模組間) 僅暴露介面，實現類包內部可見

參考資源

• Effective Java 第 3 版：項目 20 (介面優於抽象類)、項目 21 (介面設計為後繼者考慮)
• JDK 8/9/11/17 介面新特性文檔
• SOLID 原則：LSP、ISP、DIP