Java 接口設計原則：為什麼應盡量避免暴露數組

Java API 設計鐵律：接口中拒絕數組，擁抱集合

在 Java 接口設計中，直接暴露數組（如 String[] getNames()）看似簡單高效，實則違反面向對象原則，帶來效能、型別安全、API 演進等多重隱患。本文從效能實測、型別系統、封裝性三個維度深度剖析，並給出最佳替代方案。

效能迷思：數組真的更快嗎？

許多人認為數組是底層結構，直接返回應該最快。實測證明恰恰相反：

// 基準測試環境：JDK 17, n=1000, 10000 次迭代
// 返回 ArrayList 複本（紅柱） > 返回不可變列表（黃柱） > 數組 toArray(new String[0])（橙柱） > 數組 toArray(new String[size])（綠柱）

核心原因：

• ArrayList.toArray(new String[0]) 使用無型別 toArray()，JVM 內部優化極佳
• 指定大小 new String[size] 反而觸發陣列填零、類型檢查額外開銷
• Collections.unmodifiableList() 為 O(1) 操作，零拷貝，效能最優

型別安全陷阱：數組的協變性

Number[] numbers = new Integer[10];
numbers[0] = Long.valueOf(0); // 編譯通過，運行拋 ArrayStoreException

數組是協變的（Integer[] 是 Number[] 子類型），但泛型是不變的（List<Integer> 不是 List<Number> 子類型）。這導致：

• 接口暴露 Number[]，調用者可傳入 Integer[]，運行時注入 Long 導致崩潰
• 泛型集合編譯期即可阻擋此類錯誤
• 數組與泛型不兼容：new List<String>[] 編譯錯誤

封裝性缺失：數組只是結構，不是接口

最佳實踐：接口返回集合的四種模式

模式一：防禦性拷貝（需獨立快照）

public List<String> getNames() {
    return new ArrayList<>(internalList); // O(n) 拷貝，調用者可安全修改
}

模式二：不可變視圖（高效能、只讀場景）

public List<String> getNames() {
    return Collections.unmodifiableList(internalList); // O(1)，零拷貝
}
// 注意：內部列表修改會反映到視圖，迭代時可能拋 ConcurrentModificationException
}

模式三：不可變集合（Java 9+ 推薦）

public List<String> getNames() {
    return List.copyOf(internalList); // Java 10+，真正不可變，Null 安全
}

模式四：流式 API（最大靈活性）

public Stream<String> getNames() {
    return internalList.stream(); // 調用者決定收集方式、並行與否
}

遷移指南：從數組 API 升級

1. 內部實現：保留數組作為底層存儲（如 ArrayList 內部 Object[]）
2. 接口層：所有 public/protected 方法返回 List<T>、Set<T>、Stream<T>
3. 轉換層：必要時用 Arrays.asList()、List.of()、Stream.of() 適配
4. 文檔化：明確標註返回集合的可變性、線程安全性、是否為快照

Joshua Bloch《Effective Java》原話

「數組與泛型無法良好共存。若發現自己在混用它們並獲得編譯錯誤或警告，首要反應應該是用 List 替換數組。」—— 第 29 條

總結

數組是實現細節，不屬於接口契約。優秀的 Java API 設計：內部用數組追求極致效能，對外暴露集合提供豐富語義與型別安全。這不僅是風格問題，關係到系統的可維護性、可擴展性與運行時穩定性。