重新認識 Java 接口與繼承：抽象的本質與工廠模式實踐

接口 ≠ 多重繼承替代品

許多開發者誤以為接口是為彌補 Java 無多重繼承而生。實則接口與繼承本質不同：接口定義「類型」（Type），繼承定義「實現共享」（Implementation Sharing）。接口標識類具備某種能力或契約，而非提供代碼復用。

面向接口編程：數據庫連接工廠示例

// 1. 定義契約
public interface DB {
    Connection open(String url, String user, String pwd);
    void close();
}

// 2. 多種實現
public class MySQLDB implements DB { /* ... */ }
public class OracleDB implements DB { /* ... */ }

// 3. 工廠封裝實例化邏輯
public class DBFactory {
    public static DB getConnection() {
        // 可從配置讀取、環境變量、SPI 等動態決定
        return new MySQLDB();
    }
}

// 4. 客戶端代碼零耦合具體實現
DB db = DBFactory.getConnection();
db.open(url, user, pwd);

此即「普通工廠模式」。若需進一步解耦工廠本身，可引入 DBFactory 接口與多種工廠實現，演變為「抽象工廠模式」。

繼承的真實意圖：抽象而非復用

《Design Patterns》反覆強調：Favor composition over inheritance。若 B 需要 A 的 run()，應組合 A 實例並委派，而非 class B extends A：

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

繼承僅適用於「is-a」且需擴展/修改父類行為的「抽象類」場景。抽象類不可實例化，純粹作為模板，這正是繼承的正確語義。

濫用繼承的禍害

• 破壞封裝：子類依賴父類內部實現細節
• 剛性耦合：修改父類波及所有子類
• 並行繼承層次：新增一類往往需同步新增另一層次（Shotgun Surgery）

Java 取消多重繼承正是為遏制此類濫用，迫使開發者轉向接口組合與委派。

總結

• 接口：定義類型契約，支持多實現、多態、依賴倒置
• 繼承：僅用於抽象類模板方法模式，實現「受控的擴展」
• 組合/委派：首選代碼復用方式，保持類職責單一、靈活可變