深度解析：抽象類與介面的本質區別與設計選型指南

前言

面向對象設計中，「抽象類 vs 介面」是經典且高頻的架構決策點。許多教材僅列舉語法差異（多繼承、構造函數、字段修飾符），卻忽略了領域建模層面的語義本質。本文從「是什麼」與「能做什麼」兩個維度深度剖析。

一、核心隱喻：門工廠的兩種藍圖

想像一家生產各類門的工廠：

• 抽象類藍圖：定義「門」的共性本質——所有門都有顏色、材質、尺寸（屬性）；所有門都能開啟、關閉（核心行為）。這是「是什麼」的抽象。
• 介面藍圖：定義「可選功能規範」——防盜門需實現 IAlarm（報警）；智能門需實現 IFingerprint（指紋識別）。這是「能做什麼」的契約。

生產具體產品時：class SecurityDoor extends Door implements IAlarm —— 繼承門的共性，簽署報警契約。

二、本質區別對比表

三、設計選型決策樹

1. 是否存在「共同狀態與核心邏輯」需復用？ → 是 → 抽象類。
2. 是否為「跨領域、無關業務實體的行為規範」？ → 是 → 介面（如 Serializable、Comparable、Runnable）。
3. 是否需要多重組合？ → 介面（一個類可同時是 Cloneable、Serializable、Runnable）。
4. 是否需向現有穩定體系擴展功能？ → 介面（不破壞繼承樹）。

四、經典組合模式：Template Method + Strategy

// 抽象類定義算法骨架（模板方法）
abstract class AbstractParser {
    public final void parse(File f) {  // final 防止覆蓋流程
        init();
        parseHeader(f);
        parseBody(f);      // 核心變化點
        parseFooter(f);
        cleanup();
    }
    protected abstract void parseBody(File f);  // 子類實現
    // 共用工具方法...
}

// 介面定義可插拔策略
interface ICompressionStrategy {
    byte[] compress(byte[] data);
    byte[] decompress(byte[] data);
}

// 組合使用
class ZipParser extends AbstractParser {
    private ICompressionStrategy strategy;  // 依賴介面
    public ZipParser(ICompressionStrategy s) { this.strategy = s; }
    protected void parseBody(File f) { /* 使用 strategy */ }
}

抽象類管「流程骨架與共性」，介面管「變化維度與解耦」，兩者協作而非對立。

五、語言演進帶來的邊界模糊

• Java 8 default 方法：介面可提供默認實現，減少抽象類作為工具類的必要性。
• C# 介面可含靜態方法/屬性：進一步模糊邊界。
• Traits (PHP/Rust/Scala)：橫切關注點復用機制，介於兩者之間。

但語義本質未變：抽象類建模「垂直領域層次」，介面建模「水平能力切面」。

總結

別被語法細節綁架。問自己：這是定義「它是什麼」還是「它能做什麼」？需要繼承狀態還是組合行為？ 答對問題，架構自然清晰。