介面隔離原則（ISP）在 Java 設計模式中的應用與實例

定義

客戶端不應依賴它不需要的介面；一個類對另一個類的依賴應建立在最小介面上。

問題由來

「胖介面」包含過多方法，導致實現類被迫實現不需要的方法（拋出異常或空實現），違反單一職責，增加耦合與維護成本。

違反 ISP 反例：工人與機器人

interface IWorker {
    void work();
    void eat(); // 機器人不需要
}

class Worker implements IWorker {
    public void work() { System.out.println("工作中..."); }
    public void eat()  { System.out.println("吃飯..."); }
}

class Robot implements IWorker {
    public void work() { System.out.println("精準作業..."); }
    public void eat()  { throw new UnsupportedOperationException("機器人不吃飯"); } // 差劣設計
}

符合 ISP 改造：拆分介面

interface IWorkable   { void work(); }
interface IEatable    { void eat(); }

class Worker implements IWorkable, IEatable { /* 同時實現 */ }
class Robot  implements IWorkable { /* 僅實現需要的 */ }

優缺點權衡

實戰指南

1. 介面最小化且高內聚：一個介面只對應一個業務角色/能力。
2. 已有胖介面如何處理？：
   • 新代碼：直接拆分為多個小介面。
   • 舊代碼無法大幅重構：使用適配器模式包裝胖介面，暴露精簡介面給新客戶端。
3. 依賴倒置配合 ISP：高層模組依賴抽象介面，介面再按 ISP 拆分，雙重保障。

總結

1. 介面要小、精、內聚，但不過度細碎。
2. 發現胖介面 → 拆分或適配器隔離。
3. ISP 是 SOLID 中最直觀、最易落地的一條，直接提升代碼彈性與可測試性。