深度剖析 Java 介面與抽象類：語法差異、設計哲學與選型指南

核心定義

設計層面的本質差異

1. 「是一種」 vs 「有一種能力」

• 繼承抽象類：IS-A 關係。子類 是 父類的一種具體形式，共享核心屬性與行為模板。
  例：Car extends Vehicle、Dog extends Animal。
• 實現介面：HAS-A / CAN-DO 關係。類 擁有 某種能力，不限於單一繼承體系。
  例：Bird implements Flyable、Airplane implements Flyable、Penguin implements Swimmable。

2. 模板模式 vs 輻射式設計

• 抽象類 = 模板：定義算法骨架，延遲具體步驟到子類。修改模板自動影響所有子類。
  例：AbstractList 實作 addAll 依賴抽象 add。
• 介面 = 契約/標準：規範「能做什麼」，不關心「怎麼做」。修改介面需同步所有實現類（破壞性變更）。
  例：Comparable、Serializable、Runnable。

經典案例：門與警報器

// 錯誤設計：將警報塞入 Door 抽象類或介面
abstract class Door { abstract void open(); abstract void close(); abstract void alarm(); }
// 問題：防火門需要 alarm，普通門不需要 → 違反介面隔離原則

// 正確設計：分離關注點
interface Alarm { void alarm(); }
abstract class Door { void open(); void close(); }
class FireDoor extends Door implements Alarm {
    public void alarm() { /* 警報邏輯 */ }
}
class NormalDoor extends Door { /* 無 alarm */ }

Java 8+ 介面新特性：模糊邊界

• default 方法：提供預設實現，減少抽象類作為「提供默認行為」的必要性。
• static 方法：工具方法歸屬介面，如 Stream.of()。
• private 方法：default 方法間共用邏輯。

注意：介面仍無實例欄位、無建構子、無狀態。需共享狀態或定義模板算法時，抽象類仍不可替代。

選型決策樹

1. 是否需要實例狀態（非 final 欄位）或建構子邏輯？→ 抽象類
2. 是否要定義算法模板（骨架方法調用抽象步驟）？→ 抽象類
3. 是否需要多實現（一個類同時具備多種能力）？→ 介面
4. 是否只是定義無狀態契約（如標記、回調、策略）？→ 介面
5. 以上都不確定？→ 先用 介面，後續重構到抽象類成本較低（介面→抽象類屬於擴展，不破壞客戶端）。

最佳實踐原則

1. 介面優先：公開 API 以介面定義，實現類可隨時替換（依賴倒置）。
2. 抽象類作為內部實現基礎：框架內部提供 AbstractXXX 簡化擴展，對外暴露介面。
3. 避免「胖介面」：拆分為多個單一職責介面（ISP），如 Readable/Writable/Closeable。
4. 慎用 default 方法：僅用於向後兼容或極通用的輔助邏輯，業務邏輯留給實現類。
5. 組合大於繼承：若發現需繼承多個抽象類，改用介面 + 組合（策略模式）。

原始碼級範例：Java 集合框架

• Collection（介面）→ 定義契約
• AbstractCollection（抽象類）→ 實作 addAll、toString 等模板方法
• ArrayList 繼承 AbstractList 實作 get/set/add
• List 介面繼承 Collection，增加有序、可重複語義

這展示了「介面定義型別層次，抽象類提供實現骨架」的經典分層。