在日常開發中，常有同事疑惑：「為什麼每個 Service 都要定義一個介面？這不是多此一舉嗎？」這個問題看似簡單，實則觸及軟體架構的核心設計哲學。本文將透過五個實戰場景，剖析 Service 層引入介面的深層邏輯，幫助你建立更穩健的架構思維。
開源框架（如 Spring、MyBatis）大量採用介面定義擴展點。框架作者無法預知使用者的具體實現類，若無介面作為契約，框架便無法調用外部邏輯。這是「依賴倒置原則」的經典應用——高層模組不依賴低層模組，雙方皆依賴抽象。
當模組 A 需調用模組 B 尚未完成的邏輯時，先行定義介面可作為「佔位符」。雙方依介面協定並行開發，後續再替換具體實現，極大降低耦合與等待成本。
適配器模式、簡單工廠等場景中，面對多種實現（如支付渠道：支付寶、微信、銀聯），若無統一介面，調用端將充斥 `if-else` 判斷，違反開閉原則。介面讓新增實現變得優雅且安全。
專案規範難以單靠 Code Review 落地。預先定義介面，強制開發者實現特定方法簽名，從架構層面約束代碼結構，實現「慣例優於配置」的治理效果。
Java 不支援多重繼承，但可實現多個介面。一個實現類可同時實現 `UserService`、`OrderService` 等介面，並透過介面選擇性暴露方法，實現功能的「窄化」與隔離，提升封裝性。
答案是否定的。介面帶來擴展性與解耦，但也增加代碼量與維護成本。若專案規模較小、業務穩定且無多實現預期，直接使用具體類完全可行。核心原則是：**為「確定」的複雜度買單，而非為「可能」的擴展過度設計。**
面向介面編程並非教條，而是應對複雜度的利器。理解其背後的設計動機——解耦、擴展、協作、治理，才能在具體場景中做出最適決策。寫幾行介面代碼的成本極低，卻能為未來的不確定性留下緩衝空間，何樂而不為？
