深度解析 Abstract Class 與 Interface：語法、設計哲學與選型決策

Java 提供 abstract class 和 interface 兩種抽象類型定義機制，二者相似度高、甚至可互換，導致許多開發者選型隨意。實則二者差異深刻，選型直接反映對問題領域本質的理解。本文從語法層面、設計哲學、演化歷史三個維度深度剖析，給出明確選型依據。

語法層面差異速查

關鍵差異深度剖析

1. 「是什麼」 vs 「能做什麼」

• Abstract Class：定義「是什麼」—— 核心身份、本質屬性、共享狀態與行為。
  例：Animal、Vehicle、AbstractList。子類 IS-A 關係強。
• Interface：定義「能做什麼」—— 能力契約、行為規範、零狀態假設。
  例：Serializable、Comparable、Runnable。實現類 HAS-A 能力關係。

2. 默認行為與演化維護

Abstract Class 勝在默認實現：新增方法可提供默認實現，現有子類零修改。
Interface (pre-Java 8) 痛點：新增方法 = 破壞所有實現類，維護成本極高。
Java 8+ Default Methods 緩解但未消除：默認方法無法訪問實例狀態，複雜邏輯仍需抽象類協作。

3. 狀態封裝能力

• Abstract Class：可封裝共享狀態（字段）、提供受保護訪問器，子類復用邏輯與數據。
• Interface：無實例狀態，只能定義常量。狀態必須下沉到實現類，易導致重複代碼。

設計哲學層面：契約 vs 模板

Abstract Class = 模板方法模式的載體

public abstract class HttpHandler {
    // 模板方法：定義算法骨架
    public final void handle(Request req, Response resp) {
        authenticate(req);
        doHandle(req, resp);          // 子類實現
        logAccess(req, resp);
    }
    protected abstract void doHandle(Request req, Response resp);
    private void authenticate(Request req) { ... }
    private void logAccess(Request req, Response resp) { ... }
}

• 控制流程在父類，擴展點在子類
• 封裝不變部分，開放變化部分
• 體現 Hollywood Principle：「別調用我們，我們會調用你」

Interface = 策略模式/依賴倒置的契約

public interface PaymentStrategy {
    void pay(BigDecimal amount);
}

public class AlipayStrategy implements PaymentStrategy { ... }
public class WechatPayStrategy implements PaymentStrategy { ... }

public class OrderService {
    private PaymentStrategy strategy; // 依賴抽象
    public void checkout(BigDecimal amount) { strategy.pay(amount); }
}

• 定義「做什麼」，不關心「怎麼做」
• 運行時可熱插拔實現
• 支撐 OCP（開閉原則）：新增支付方式零修改 OrderService

演化視角：Java 8/9/17+ 如何重塑邊界

但核心差異未變：接口仍無構造器、無實例字段、無法強制初始化邏輯。

選型決策樹：遇到這種情況怎麼選？

1. 需要構造器初始化、共享字段、模板方法 → abstract class
2. 定義能力契約、多實現熱插拔、跨層級解耦 → interface
3. 既要共享代碼/狀態，又要多實現 → 組合模式：抽象類供繼承復用 + 實現接口對外暴露契約
4. 純標記、無方法 → interface (Marker Interface)
5. 工具方法集、無狀態 → interface + default (Java 8+) 或 final class + 靜態方法

經典案例：Java 集合框架

• Collection、List、Set、Map → Interface（定義契約）
• AbstractCollection、AbstractList、AbstractMap → Abstract Class（提供默認實現、共享 size/modCount 等狀態）
• ArrayList → extends AbstractList implements List, RandomAccess, Cloneable, Serializable

雙層設計 = 契約穩定 + 實現靈活 + 代碼復用最大化。

總結

Abstract Class 為「共享實現」服務，Interface 為「定義契約」服務。
選型時問自己：我是在提煉「共同骨架」還是「對外承諾」？

掌握這一本質，你的類圖將不再隨意，而是精準表達領域模型的結構意圖。