Java 介面與抽象類深度對比：語法規範、設計哲學、門與警報經典案例實戰

介面與抽象類是 Java 抽象機制的雙支柱，語法相似但設計意圖截然不同。本文從語法層面、設計層面、經典案例三個維度徹底釐清，幫你在架構決策中做正確選擇。

一、語法層面硬性規範對比

二、設計層面核心差異

1. 抽象維度不同

• 抽象類：類級抽象 —— 對「一類事物」整體建模（屬性 + 行為），如 Animal、Vehicle
• 介面：行為級抽象 —— 對「某種能力」建模，如 Flyable、Serializable、Comparable

2. 關系語義不同

3. 設計模式角色不同

• 抽象類 = 模板模式：定義算法骨架，子類填充細節。新增方法可提供默認實現，不破壞既有子類
• 介面 = 契約/輻射模式：定義規範，所有實現類必須遵守。修改介面強制所有實現類變更

三、經典案例：門與警報系統

錯誤設計一：全部塞進抽象類

abstract class Door {
    abstract void open();
    abstract void close();
    abstract void alarm(); // 強制所有門都有警報
}

問題：防火門、普通門不需要警報，違反介面隔離原則。

錯誤設計二：全部塞進介面

interface Door {
    void open();
    void close();
    void alarm(); // 火災報警器實現此介面卻無 open/close
}

問題：火災報警器不是門，強制實現無意義方法，違反單一職責。

正確設計：職責分離 + 組合

// 核心門行為：抽象類（模板）
abstract class Door {
    public abstract void open();
    public abstract void close();
}

// 擴展能力：介面（契約）
interface Alarm {
    void alarm();
}

// 組合：既是門又有警報
class AlarmDoor extends Door implements Alarm {
    @Override public void open() { /* 開門邏輯 */ }
    @Override public void close() { /* 關門邏輯 */ }
    @Override public void alarm() { /* 警報邏輯 */ }
}

// 純警報設備：僅實現介面
class FireAlarm implements Alarm {
    @Override public void alarm() { /* 火災警報 */ }
}

四、決策指南：何時選擇哪個？

1. 需要共享代碼/狀態 → 抽象類（如模板方法、基礎實體類）
2. 定義跨體系通用能力 → 介面（如 Comparable、Runnable、JPA Repository）
3. 預期頻繁演進 → 抽象類（可加默認方法平滑過渡）
4. 需要多重組合 → 介面（類可實現多個介面）
5. 簡單數據載體 → 介面 + Record (JDK 16+) 或 Lombok @Value

五、JDK 8+ 介面演進影響

• default 方法：介面可提供實現，減少抽象類優勢
• static 方法：工具方法歸屬介面，如 Stream.of()
• private 方法：默認方法間共享邏輯

但本質未變：介面仍無實例狀態、無構造器、多實現語義不變。