Java 抽象類深度解析：語法規則、設計模式與實戰應用

Java 抽象類深度解析：語法規則、設計模式與實戰應用

抽象類是 Java 實現多態與程式碼復用的核心機制之一。本文從語法規範、設計意圖、模板方法模式、介面對比、實戰陷阱五個維度系統講解抽象類的核心知識體系。

一、語法規範與核心規則

二、設計意圖：為什麼需要抽象類？

1. 定義契約與預設行為：規範子類必須實現的核心行為 (抽象方法)，同時提供通用邏輯 (具體方法) 避免重複
2. 封裝變化點：將「不變的骨架」固化在父類，「可變的細節」延遲到子類實現
3. 受控繼承：比介面更強的約束 (單繼承)，適合「is-a」關係緊密的類別體系
4. 狀態共享：抽象類可擁有實例欄位 (狀態)，介面僅能有常量 (Java 8 前)

三、經典設計模式：模板方法模式

抽象類定義演算法骨架，將特定步驟延遲到子類實現，符合「好萊塢原則」——「別調用我們，我們會調用你」。

/**
 * 資料導入模板：讀取 → 驗證 → 轉換 → 持久化 → 通知
 */
public abstract class DataImporterTemplate<T> {
    
    // 最終方法：鎖定演算法流程，禁止子類覆寫
    public final void importData(InputStream input) {
        List<T> rawData = readData(input);           // 1. 讀取 (抽象)
        List<ValidatedRecord<T>> validated = validate(rawData); // 2. 驗證 (模板提供預設)
        List<Entity> entities = transform(validated); // 3. 轉換 (抽象)
        persist(entities);                            // 4. 持久化 (模板提供預設)
        notifyComplete(entities.size());              // 5. 通知 (鉤子方法)
    }
    
    // 抽象方法：子類必須實現
    protected abstract List<T> readData(InputStream input);
    protected abstract List<Entity> transform(List<ValidatedRecord<T>> validated);
    
    // 具體方法：提供預設實現，子類可選擇性覆寫
    protected List<ValidatedRecord<T>> validate(List<T> rawData) {
        return rawData.stream()
            .map(this::validateSingle)
            .collect(Collectors.toList());
    }
    
    protected void persist(List<Entity> entities) {
        entityRepository.saveAll(entities);
    }
    
    // 鉤子方法：預設空實現，子類按需擴充
    protected void notifyComplete(int count) {
        log.info("導入完成，共 {} 筆", count);
    }
    
    // 私有輔助方法：封裝內部細節
    private ValidatedRecord<T> validateSingle(T item) { ... }
}

子類實現範例

public class ExcelUserImporter extends DataImporterTemplate<Row> {
    @Override
    protected List<Row> readData(InputStream input) {
        // POI 解析 Excel 行
    }
    
    @Override
    protected List<Entity> transform(List<ValidatedRecord<Row>> validated) {
        // Row → UserEntity 轉換邏輯
    }
    
    @Override
    protected void notifyComplete(int count) {
        super.notifyComplete(count);
        emailService.sendAdminReport(count);
    }
}

四、抽象類 vs 介面：選型決策指南

決策口訣：
需要共享代碼/狀態 → 抽象類
定義能力契約、多實現、插件化 → 介面
兩者兼備 → 抽象類實現介面 (如 AbstractList implements List)

五、實戰陷阱與最佳實踐

1. 過度使用繼承導致脆弱基類：父類變更波及所有子類。
   → 組合優於繼承，引入策略模式、裝飾器模式替代深層繼承鏈。
2. 建構子中調用抽象方法：子類欄位尚未初始化，導致 NPE 或錯誤行為。
   → 建構子僅初始化父類狀態，複雜初始化移至 init() 模板方法或工廠方法。
3. 抽象類膨脹成「上帝類」：塞入過多業務邏輯。
   → 拆分為多個小介面 + 組合，或使用 Template Method 精簡骨架。
4. 忽略 final 保護演算法骨架：子類誤覆寫 template method 破壞流程。
   → 公開模板方法標記 final，內部步驟 protected abstract/hook。
5. 與介面混用造成鑽石繼承問題：Java 8 default 方法衝突。
   → 實現類顯式覆寫衝突方法並選擇調用 super 或介面名.super.method()。

六、JDK 源碼經典案例賞析

• AbstractList：實現 List 介面，提供隨機存取骨架，子類僅需實現 get(int)、size()，其餘 add/remove/indexOf 等均有預設實現
• HttpServlet：無抽象方法但宣告 abstract，強制繼承覆寫 doGet/doPost 等業務方法
• InputStream/OutputStream：定義 read()/write() 抽象方法，提供 read(byte[])、skip() 等模板實現
• Collections.sort()：內部使用 List.sort(Comparator) → TimSort，List 介面 default 方法委託 Collections.sort()，雙向協作

七、總結

抽象類是「不完整的類」，以「抽象」描述契約，以「具體」復用邏輯。掌握模板方法模式、合理劃分抽象與具體邊界、警惕繼承濫用，能讓你設計出既靈活又穩健的類別體系。現代 Java 開發中，介面配合 default 方法已承擔部分抽象類職責，但抽象類在狀態管理、強約束繼承鏈、建構子鏈初始化等場景仍不可替代。