面向介面編程：從「面向對象」到「面向契約」的架構思維轉變

前言：為什麼資深架構師總強調「面向介面編程」？

在面向對象系統中，對象間的協作關係遠比對象內部實現更關鍵。類之間的通訊、模組間的交互，在系統設計初期即需確立穩定契約。然而許多開發者僅停留在「實現介面」的被動層面，缺乏「設計介面」的主動意識，導致：

• 頻繁抱怨「別人改代碼影響了我」—— 介面未設計好，實現細節外洩。
• 模組微調引發連鎖修改—— 模組邊界模糊，介面未隔離變化點。

本文深入剖析介面本質、設計原則、環境語境與組件模型，助你建立真正的「面向契約」架構思維。

一、介面的本質：定義與實現的分離

介面 = 規範、約束、契約，而非單指 Java interface 關鍵字。

• 抽象體：對整體的抽象，對應 abstract class (含狀態與部分實現)。
• 抽象面：對某一方面行為的抽象，對應 interface (純契約)。一個實體可實現多個抽象面。
• 名實分離：介面定義「做什麼」，實現決定「怎麼做」。變更實現不影響調用者，反之亦然。

二、介面設計的三大核心原則

1. 單一職責與介面隔離 (ISP)

介面應盡可能小、專一，客戶不應依賴它不需要的方法。大介面導致實現類被迫實現無關方法，耦合度飆升。

// 違反 ISP：強迫所有實現類關心持久化、序列化、網路傳輸
interface UserService { save(); serialize(); sendOverNetwork(); }

// 遵循 ISP：拆分為獨立介面
interface UserRepository { save(User u); }
interface UserSerializer { byte[] serialize(User u); }
interface UserTransmitter { void send(User u); }

2. 依賴倒置 (DIP)

高層模組不應依賴低層模組，二者都應依賴抽象 (介面)。抽象不應依賴細節，細節應依賴抽象。

// 違反 DIP：Controller 直接依賴 MySQL 實現
class UserController { private MySqlUserDao dao = new MySqlUserDao(); }

// 遵循 DIP：Controller 依賴介面，具體實現由 DI 容器注入
class UserController { 
    private UserRepository repo; 
    @Autowired UserController(UserRepository repo) { this.repo = repo; }
}

3. 契約優先與版本演進

• 先定介面 (WSDL/Java Interface/Protobuf/OpenAPI)，再雙邊並行開發實現與消費者。
• 介面發布後嚴禁破壞性變更；新增功能採用新介面或參數對象擴展，舊介面標記 @Deprecated 並提供遷移期。

三、介面的環境語境 —— 常被忽視的關鍵因素

系統論視角：環境 = 介面所處的空間與外部影響因素總和。同一介面在不同語境下語義截然不同：

• 本地進程內介面：傳遞物件引用、共享記憶體、同步調用、事務邊界共享。
• 分散式遠程介面 (RMI/gRPC/REST)：傳遞資料傳輸物件 (DTO)、序列化開銷、網路延遲、部分失敗、冪等性、安全認證。
• 事件驅動介面：非同步、最終一致性、事件溯源、重試機制。

脫離環境談介面設計是空中樓閣。介面契約必須顯式包含環境假設：同步/非同步、事務語義、錯誤碼、超時、重試、安全上下文傳遞等。

四、組件開發模型 (3C) 與介面的關係

組件 = Contract (介面契約) + Code (實現) + Configuration (配置/部署描述)，三者缺一不可：

• Contract：定義服務邊界與交互協議 (Java Interface / WSDL / IDL)。
• Code：實現契約，可被多種實現替換 (Mock、Stub、生產版)。
• Configuration：指定具體實現類、連線參數、事務屬性、安全策略，實現「不改代碼切換實現」。

這正是 Spring/IoC 容器、OSGi、Dubbo、gRPC 等框架的核心運作模型。

五、澄清常見誤區

六、實戰檢核表：你的介面設計合格嗎？

1. [ ] 介面是否僅暴露「做什麼」，隱藏「怎麼做」？
2. [ ] 是否遵循 ISP，拆分為最小專用介面？
3. [ ] 高層模組是否僅依賴介面，透過 DI 獲取實現？
4. [ ] 介面文檔是否包含：前置條件、後置條件、副作用、異常碼、事務語義、冪等性、線程安全、性能 SLA？
5. [ ] 是否考慮了部署環境 (本地/遠程/事件) 對契約的影響？
6. [ ] 是否有版本演進策略 (相容性保證、遷移路徑)？
7. [ ] 是否提供 Mock/Stub 實現支援測試與並行開發？

結語

面向介面編程，本質是「面向抽象契約編程」。它要求架構師像設計網路協議 (RFC) 一樣設計模組邊界：嚴謹定義語法、語義、約束與演進規則，而非隨意提取類的 public 方法湊成介面。唯有將「介面設計」上升為獨立、前置、持續的架構活動，系統才能獲得真正的鬆散耦合、可替換性與長期演進能力。下次動筆寫 interface 前，請先問自己：這是一個契約，還只是一組方法簽名？