Java 介面設計三大範式：從業務解耦到資料結構定義

關於「介面設計是自上而下、自下而上，還是適配器模式」的爭論，本質上忽略了介面在 Java 中的多重語義。實際開發中，介面設計模式取決於使用場景，而非單一流程。

介面的三種核心用法

1. 業務解耦介面（面向介面程式設計，依賴倒置）

場景：分層架構（Controller-Service-DAO）、微服務邊界、策略模式、外掛擴充點。
設計流程：自上而下。先依據業務邊界定義介面契約（UserService、PaymentGateway），再由不同團隊或模組實作（UserServiceImpl、AlipayGateway/WechatGateway）。
關鍵：介面屬於呼叫方，由呼叫方定義所需契約，實作方依賴介面而非具體類。

2. 資料結構/演算法骨架介面（框架/庫設計）

場景：集合框架（List/Map/Set）、流處理（Stream）、自定義資料結構。
設計流程：自上而下。先抽象出核心操作語義（add/get/size），定義介面（Map<K,V>），再提供多種實作（HashMap/TreeMap/ConcurrentHashMap）。
關鍵：介面定義行為契約與複雜度承諾（如 get O(1) vs O(log n)），實作遵守契約並針對不同場景優化。

3. 函數式介面 / 回調介面（Java 8 前模擬 Lambda）

場景：事件監聽（ActionListener）、比較器（Comparator）、執行緒任務（Runnable）、模板方法鉤子。
設計流程：無固定流程。介面僅作為單一方法的類型載體，隨業務需要臨時定義（@FunctionalInterface），不涉及複雜層級結構。
關鍵：Java 8+ 應優先使用 Function/Predicate/Consumer 等標準函數式介面，減少自訂介面。

常見誤區澄清

實戰建議

1. 識別場景：新模組從業務邊界切分 → 類型 1；工具庫/框架 → 類型 2；單一行為傳遞 → 類型 3。
2. 介面粒度：遵循介面隔離原則（ISP），Map 不應繼承 List；UserService 不應包含 sendEmail。
3. 演進策略：公開 API 介面極度謹慎變更（新增方法用預設方法或新介面）；內部介面可隨重構調整。
4. 文檔化契約：Javadoc 必須說明執行緒安全性、拋出異常、複雜度、副作用等非功能性承諾。

結論：不存在放之四海而皆準的「介面設計流程」，依業務語境選擇設計模式，才是資深工程師的思維模型。