Java 介面與繼承本質區別：從工廠模式看抽象的真諦

許多開發者誤以為介面是為了「替代多重繼承」。實則不然：介面的核心價值是「標識類別型別」，實現抽象；繼承的本質同樣是抽象，而非程式碼重用。本文以資料庫連線切換為例，層層推導工廠模式，揭示介面與繼承的設計哲學。

從具體類到介面抽象

假設有 MySQL、SQLServer、Oracle 三個類，各自實現連線邏輯。為了讓上層業務不依賴具體類，定義介面：

public interface DB {
    Connection openDB(String url, String user, String password);
    void close();
}

各資料庫類實作 implements DB。但上層仍需 new MySQL() 等具體實例化，違反「開閉原則」。

引入工廠模式

public class DBFactory {
    public static DB getConnection() {
        // 可從配置檔讀取決定實例化哪個類
        return new MySQL(); 
    }
}

客戶端僅依賴 DB 介面：DB db = DBFactory.getConnection();。具體實例化邏輯封裝在工廠，後續擴充 PostgreSQL 只需修改工廠，業務碼零變動。

介面 ≠ 多重繼承替代品

• C++ 多重繼承混合了「型別繼承」與「實作繼承」，易產生鑽石繼承、狀態同步等問題。
• Java 介面純粹定義契約（型別），不攜帶狀態與實作，配合單繼承避免複雜性。
• GoF 設計模式核心是「對介面編程，而非對實作編程」，介面是實現此原則的語言級支撐。

繼承的真正意義：抽象，而非重用

若類 B 想用類 A 的 run()，直接 extends A 是懶惰做法。正確做法是組合/委派：

class B {
    private A a = new A();
    void run() { a.run(); } // 委派給 A 實例
}

優點：B 不綁定 A 的實作細節，可輕易換成 A2、A3，符合「合成復用原則」。

何時使用繼承？

• 只有在「is-a」關係明確，且需要多型時（如抽象類定義模板方法）。
• 抽象類本身不可實例化，僅提供模板，這才是繼承的正確舞臺。

結語

Java 取締多重繼承、引入介面，迫使開發者區分「型別繼承」與「實作繼承」，本質是推動面向介面設計。濫用繼承是軟體腐化的萬惡之源；善用介面+組合+工廠，才能構建高內聚、低耦合、可演進的系統。