Java 介面進階：預設方法、菱形衝突與泛型契約

當「契約」開始有了預設行為：介面為什麼不再只是空殼？

在入門篇裡，我們把介面（interface）理解成一份「純粹的契約」——它只規定方法的簽章（signature），不規定怎麼做，讓兩個原本不相干的類別可以透過共同的型別合作。那是一張白紙黑字的合約：你答應提供 area()，我就把你當成 Shape 來用。

但如果你打開 Java 8 之後的標準函式庫，會發現 java.util.List、java.lang.Comparable、java.util.function.Function 這些介面裡面，竟然塞滿了「有實作的方法」。List 介面裡的 sort()、stream()、forEach() 都帶著程式碼。這還是「純粹的契約」嗎？一份合約裡怎麼會自己附上「履約範本」？

這篇進階文章，要帶你越過「介面 = 抽象方法集合」這個入門印象，去看介面真正棘手也真正有力的地方：預設方法（default method）帶來的多重繼承、菱形衝突（diamond problem）、介面與抽象類別的設計權衡、以及泛型介面如何讓契約本身變得可程式化。這些是判斷一個 Java 工程師是否真的理解抽象的分水嶺。

預設方法：在不破壞既有程式碼的前提下擴充契約

先回答破題的疑問。Java 8 為什麼要讓介面可以有實作？答案是一個非常實際的工程困境：介面演化（interface evolution）。

假設你在 2010 年發布了一個 Collection 介面，全世界有上萬個類別實作了它。到了 2014 年，你想加一個 stream() 方法。如果介面只能有抽象方法，那麼你一旦在介面加上 stream()，所有既有的實作類別全部編譯失敗——因為它們沒有實作這個新方法。這在實務上等於宣告「這個介面永遠不能再加新方法」，太僵硬了。

預設方法就是解法：介面可以提供一個 default 實作，實作類別沒有覆寫（override）時就用這個預設版本。

public interface Greeter {
    String name();

    // 預設方法：帶有實作，實作類別可不覆寫
    default String greet() {
        return "你好，我是 " + name();
    }
}

public class Student implements Greeter {
    private final String studentName;
    public Student(String n) { this.studentName = n; }

    @Override
    public String name() { return studentName; }
    // 沒有覆寫 greet()，自動繼承預設實作
}

Greeter g = new Student("小華");
System.out.println(g.greet());  // 你好，我是 小華

關鍵是：Student 只實作了 name()，就自動獲得 greet()。如果未來在 Greeter 加一個 default String farewell()，Student 不需要任何修改就能繼續編譯。這就是 default method 守護的「回溯相容性（backward compatibility）」。

但這也悄悄打開了一道門：介面現在能攜帶行為了。而「能繼承多個介面」加上「介面能攜帶行為」，等於 Java 終於擁有了某種形式的多重繼承（multiple inheritance）——而多重繼承正是 C++ 時代惡名昭彰的麻煩來源。

菱形問題：當兩份契約給了你互相矛盾的範本

Java 在類別層級刻意禁止多重繼承（一個類別只能 extends 一個父類別），就是為了避開「菱形問題」。但 default method 把行為帶進介面後，菱形問題從後門溜了進來。

考慮這個情境：

interface A {
    default String hello() { return "來自 A"; }
}

interface B {
    default String hello() { return "來自 B"; }
}

// C 同時實作 A 和 B，兩者都提供了 hello() 的預設實作
class C implements A, B {
    // 這裡會編譯失敗！
}

C 同時繼承了 A.hello() 和 B.hello() 兩個衝突的預設實作——編譯器無從決定該用哪一個。這就是菱形問題的本質：多條繼承路徑提供了相同方法的不同實作。

C++ 用虛擬繼承（virtual inheritance）等複雜機制處理這件事，結果是語意難懂。Java 的選擇更簡單直接：衝突時強制由子類別明確解決。你必須覆寫該方法，並用特殊語法指定要用哪個介面的版本：

class C implements A, B {
    @Override
    public String hello() {
        // 用 介面名.super.方法() 指定來源
        return A.super.hello() + " 與 " + B.super.hello();
    }
}

System.out.println(new C().hello());  // 來自 A 與 B

Java 的衝突解決有三條優先規則，理解它們能讓你預測任何複雜繼承的結果：

1. 類別優先於介面（Class wins）：如果一個方法同時來自父類別與介面，父類別的具體實作勝出。
2. 更具體的介面優先（More specific interface wins）：若介面 B 繼承（extends）介面 A，且兩者都有同名 default，B 的版本勝出，因為它「更靠近」。
3. 否則衝突，強制覆寫：如果是平行、無繼承關係的兩個介面（如上面的 A、B），編譯器拒絕猜測，要求你手動覆寫。

第二條規則值得用例子確認：

interface A {
    default String hello() { return "來自 A"; }
}
interface B extends A {
    default String hello() { return "來自 B（更具體）"; }
}
class D implements A, B {
    // 不需覆寫！B 更具體，自動勝出
}

System.out.println(new D().hello());  // 來自 B（更具體）

D 同時宣告 implements A, B，看似又是菱形，但因為 B extends A，B.hello() 在繼承鏈上更具體，編譯器能明確決定，因此不強制覆寫。

靜態方法與私有方法：介面作為「行為工具箱」

預設方法之外，Java 8 還允許介面有 static 方法，Java 9 進一步允許 private 方法。這讓介面從「純契約」演化成一個能容納完整工具集的單元。

public interface JsonSerializable {
    String toJson();

    // 靜態工廠方法：不需實例就能呼叫
    static JsonSerializable empty() {
        return () -> "{}";   // lambda 實作單一抽象方法
    }

    // 預設方法呼叫私有輔助方法
    default String toPrettyJson() {
        return indent(toJson());
    }

    // 私有方法：只供介面內部的 default 方法共用，外部看不到
    private String indent(String raw) {
        return raw.replace(",", ",\n  ");
    }
}

這裡有三個層次的設計：static 方法 empty() 提供了一個與任何實例無關的工廠；default 方法 toPrettyJson() 提供可被覆寫的行為；private 方法 indent() 則把 default 方法之間的共用邏輯封裝起來，不污染公開契約。

私有方法的存在說明了一件事：Java 設計者承認介面已經會累積真實的實作邏輯，因此需要「介面內部封裝」的機制——這在概念上已經非常接近一個（不能有實例欄位的）類別了。

那麼，介面和抽象類別（abstract class）現在還有差別嗎？有，而且這個差別決定你該選哪一個。

介面 vs 抽象類別：在「能力」與「身份」之間選擇

入門篇可能簡單地說「介面是契約、抽象類別是骨架」。進階地看，兩者的核心差異可以濃縮成三點：

最關鍵的是狀態。介面不能持有實例欄位，因此 default method 是「無狀態的行為」——它只能呼叫介面契約裡的抽象方法來運算，不能讀寫物件的內部欄位。抽象類別則可以有 protected 欄位、建構子、初始化邏輯，提供「有狀態的骨架」。

設計準則因此很清楚：

• 當你要表達橫切的能力（一個類別「也能」被排序、被序列化、被比較），且這能力可以加在任何繼承體系上 → 用介面。Comparable、Serializable、Runnable 都是能力，不是身份。
• 當你要表達一個家族的共同本質與共享狀態（所有 AbstractList 都有相同的內部結構與部分實作） → 用抽象類別。

實務上 Java 函式庫常見「介面 + 抽象骨架類別」的雙層搭配：List（介面，定義契約）配 AbstractList（抽象類別，提供大部分共用實作）。你實作新集合時繼承 AbstractList 省力，但對外型別仍是 List，享有介面的彈性。這個模式叫 Skeletal Implementation（骨架實作），是《Effective Java》明確推薦的設計。

看一個例子：用泛型介面把「契約」變成可程式化的型別

介面真正的威力，在它與泛型（generics）結合時才完全展開。Comparable<T> 是最好的教材：

public interface Comparable<T> {
    int compareTo(T other);   // 契約：回傳負/零/正 代表 小於/等於/大於
}

注意型別參數 T。這讓 compareTo 在編譯期就是型別安全的——Integer implements Comparable<Integer>，所以你不可能把 Integer 拿去跟 String 比較，編譯器會擋下來。對比早期 Java（沒有泛型）的 compareTo(Object)，後者要在執行期 cast，隨時可能 ClassCastException。

來看一個自訂類別如何接上整個 Java 排序生態系：

public class Grade implements Comparable<Grade> {
    private final String course;
    private final int score;

    public Grade(String course, int score) {
        this.course = course;
        this.score = score;
    }

    @Override
    public int compareTo(Grade other) {
        // 依分數由小到大；契約規定回傳 int 正負號
        return Integer.compare(this.score, other.score);
    }

    @Override
    public String toString() { return course + ":" + score; }
}

List<Grade> grades = new ArrayList<>(List.of(
    new Grade("微積分", 78),
    new Grade("線性代數", 92),
    new Grade("程式設計", 85)
));

Collections.sort(grades);   // 只因為 Grade 履行了 Comparable 契約
System.out.println(grades); // [微積分:78, 程式設計:85, 線性代數:92]

Collections.sort 不認識 Grade，它只認識 Comparable 契約。你只寫了一個 compareTo，就免費接上了 Collections.sort、TreeSet、TreeMap、Arrays.sort、Stream.sorted() 整套排序設施。這就是「面向介面編程（program to an interface）」的複利效應：你履行一份小契約，換來整個生態系的協作。

更進階一步，Comparator<T> 是另一個泛型介面，它把「比較邏輯」本身抽象成一個物件，且大量使用 default method 來組合：

Comparator<Grade> byScore = Comparator.comparingInt(g -> g.score());
Comparator<Grade> byScoreDesc = byScore.reversed();          // default method
Comparator<Grade> combo = byScore.thenComparing(g -> g.course());  // default method

grades.sort(combo);

reversed()、thenComparing() 全都是 Comparator 介面上的 default method。你看到了嗎——default method 在這裡不是為了相容性，而是讓介面本身提供一套可組合的迷你 DSL（領域特定語言）。這是介面演化後最優雅的用途。

函式介面與 Lambda：單一抽象方法的契約

當一個介面恰好只有一個抽象方法時，它叫做函式介面（functional interface），可以用 lambda 表達式直接實作。這是 Java 把介面抽象推到極致的地方。

@FunctionalInterface
interface Transformer {
    int apply(int x);   // 唯一的抽象方法
    // 可以有任意多個 default / static 方法，仍算函式介面
}

Transformer square = x -> x * x;       // lambda 就是這個介面的實例
Transformer increment = x -> x + 1;
System.out.println(square.apply(5));   // 25
System.out.println(increment.apply(5));// 6

@FunctionalInterface 標註讓編譯器替你檢查「真的只有一個抽象方法」。java.util.function 套件裡 Function<T,R>、Predicate<T>、Supplier<T>、Consumer<T> 全是函式介面，它們是整個 Stream API 與函數式風格的地基。

值得釐清的迷思：lambda 不是匿名類別（anonymous class）的語法糖那麼簡單。在位元組碼層級，lambda 用 invokedynamic 指令延遲生成，通常不會為每個 lambda 產生一個 class 檔，效能與記憶體都優於匿名內部類別。但語意上你只需記住：lambda 是函式介面的一個實例，它履行了那唯一一條契約。

重點回顧

• 預設方法（default method）讓介面能攜帶實作，核心動機是「介面演化」——在不破壞既有實作類別的前提下擴充契約，守護回溯相容性。
• default method 帶來有限的多重繼承，因而引入菱形問題；Java 用三條規則化解：類別優先於介面、更具體的介面優先、平行衝突則強制子類別覆寫並以 介面名.super.方法() 指定來源。
• 介面 vs 抽象類別的本質差異是「狀態」：介面不能有實例欄位（行為無狀態），抽象類別可以；語意上介面表達「能做什麼（能力）」，抽象類別表達「是什麼（身份）」。
• 泛型介面（如 Comparable<T>、Comparator<T>）讓契約型別安全且可組合；履行一份小契約即可接上整個排序生態系，default method 更讓介面提供可組合的迷你 DSL。
• 函式介面（單一抽象方法）配 lambda 是抽象的極致：一個 lambda 就是該介面的一個實例，且底層以 invokedynamic 高效實現，並非單純的匿名類別語法糖。

深入探討（研究所視角）

型別理論視角：介面作為結構化的有界量化。 從程式語言理論看，Java 的泛型介面結合了參數多型（parametric polymorphism）與子型別多型（subtype polymorphism）。Comparable<T> 的真正威力在於有界型別參數（bounded type parameter）與遞迴泛型界限（recursive generic bound，F-bounded polymorphism）。考慮一個泛型排序工具的簽章：

public static <T extends Comparable<? super T>> void sort(List<T> list)

這裡 T extends Comparable<? super T> 是 F-bounded 多型的經典寫法：型別 T 必須能與「自己或自己的某個父型別」比較。? super T 這個下界萬用字元（lower-bounded wildcard）允許 Student 即使只實作了 Comparable<Person>（其父類別）也能被排序。這對應 PECS 原則（Producer Extends, Consumer Super）：Comparable 是 T 的消費者（它消費 T 來產生比較結果），故用 super。理解這層界限，是讀懂 Java 標準函式庫泛型簽章的鑰匙。

菱形問題的形式化與 C3 線性化的對照。 Java 對 default method 衝突採「靜態拒絕（compile-time rejection）」策略，而非像 Python 那樣用 C3 線性化（C3 linearization，即 MRO，Method Resolution Order）在執行期計算一個確定的方法解析順序。兩者是不同的設計哲學：Python 接受任意菱形並用演算法給出一個全序（total order）；Java 則認為「沉默地替你選一個」太危險，寧可在編譯期報錯逼你顯式決定。這個取捨反映了 Java「顯式優於隱式」的語言設計價值觀——當語意有歧義時，把決定權交還給程式設計者，而非埋進語言的解析演算法裡。值得思考的延伸問題：若 Java 採用 C3 線性化，A.super.hello() 這類語法是否就不必要？答案是仍會需要，因為線性化只給「預設選擇」，覆寫者偶爾仍想明確呼叫被線性化排在後面的那個版本。

介面與「混入（mixin）」的關係。 帶 default method 的介面在語意上非常接近其他語言的 mixin 或 trait（如 Scala 的 trait、Rust 的 trait default method）。但 Java 介面有一個刻意的限制：不能持有狀態。Scala trait 可以有欄位，因此能組合出有狀態的混入，但代價是更複雜的初始化順序與線性化規則。Java 用「介面無狀態 + 抽象類別有狀態」的二分法，避開了「有狀態多重繼承」的初始化夢魘——這也解釋了為什麼 Skeletal Implementation 模式（介面定義契約、抽象骨架類別補上有狀態實作）會成為慣用法：它把「能力的組合」與「狀態的繼承」分到兩個正交的維度，各自只承擔自己擅長的責任。

延伸閱讀方向。 若想再深入，可探討：(1) JVM 中 default method 的分派如何透過 invokeinterface 與 default method 表實現，以及它對效能的微小影響；(2) 密封介面（sealed interface，Java 17）如何讓介面在「開放擴充」與「窮舉式模式比對（exhaustive pattern matching）」之間取得平衡，這是代數資料型別（algebraic data type）在 Java 的落地；(3) Comparator 的 default method 組合子（thenComparing、reversed）作為單子（monoid）結構的觀察——比較器在 thenComparing 下構成一個有單位元（自然順序）的可結合運算，這把抽象代數的視角帶回了日常的排序程式碼。