接口隔离原则（ISP）：客户端不应依赖它不用的方法
更新时间：2026-08-25。本文从语义与意义两个层面论述接口隔离原则（Interface Segregation Principle, ISP）：接口的粒度不该由"实现者的功能全集"决定，而该由"调用方的使用视角"决定。
一、语义：ISP 到底在说什么
ISP 的经典表述：客户端不应被迫依赖它不使用的方法（Clients should not be forced to depend on interfaces they do not use）。
拆成两个动作理解：
| 动作 | 语义 |
|---|---|
| 依赖（depend on） | 在 C++ 中"依赖接口"≈ 持有接口类型指针、调用它的方法、编译期包含它的头文件 |
| 不使用（do not use） | 客户端只用到接口的一部分方法，其余方法对它毫无意义 |
语义要点：接口的切分边界不是"实现者会什么"，而是"客户端需要什么"。同一个实现类可以为多个角色各提供一个视角接口；接口是按使用场景（角色） 定义的，不是按功能全集定义的。
与 SRP 的区别：SRP 管"类"（一个类一个职责），ISP 管"接口"（一个接口面向一个客户端角色）。一个类可以有多个接口（多视角），每个接口都保持单一。
经典反例——胖接口（Fat Interface）：Worker 接口含 work()、eat()、sleep()；Robot 实现它却不需要 eat/sleep，只能空实现或抛异常——这与 LSP 的"空实现"症状同源。
二、意义：为什么接口粒度决定耦合成本
- 编译与传递依赖：C++ 客户端包含胖接口头文件，等于传递依赖了它不用的所有东西——改任何无关方法都触发重编译，大型项目编译成本爆炸。
- 实现的空壳化：被迫实现不用的方法 → 空实现/抛异常 → 埋下 LSP 违约种子。
- 测试隔离：客户端测自己行为时，mock 一个胖接口意味着要 mock 一堆不用的方法，测试意图被噪音淹没。
- 演进安全：接口越胖，给"某个客户端"加方法就越可能波及其他客户端（都依赖同一接口，都得跟着变）。接口隔离后，每个客户端的演进独立。
三、违反与守好：对比类图
违反 ISP 的样子——一个胖接口拖累所有实现者：
守住 ISP 的样子——按客户端角色拆分接口：
对比分析
| 维度 | 违反 ISP（胖接口） | 守住 ISP（角色接口） |
|---|---|---|
| 实现负担 | 每个实现者被迫实现所有方法 | 各实现各取所需 |
| 空壳代码 | 空实现/抛异常蔓延 | 无空壳，接口即契约 |
| 编译依赖 | 客户端传递依赖无关方法 | 客户端只含所需接口头文件 |
| 演进 | 加方法波及其他客户端 | 各角色接口独立演进 |
| 测试 | mock 胖接口噪音大 | mock 小接口意图清晰 |
四、如何判断：实践检查清单
| 症状 | 判断 |
|---|---|
| 接口方法很多但某个实现大量空实现/抛异常 | 已违反，按角色拆分 |
| 一个接口的客户端群体差异极大（如"管理员"与"游客"共用） | 已违反，拆视角 |
| 接口超过 ~5 个方法且主题不单一 | 检查是否存在多个角色视角 |
| 改接口加方法导致大量无关实现被迫改动 | 已违反（客户端一起变） |
| 每个客户端依赖的接口方法恰好都是它用的 | ✅ 符合 ISP |
边界警示：ISP 不是"接口越小越好"。接口粒度应跟随真实调用场景：两个客户端永远一起使用同一组方法，合并成一个接口是合理的（避免接口碎片化）。判断依据是"客户端的使用视角"，不是方法数量。
五、与设计模式的关系
ISP 指导模式中的接口设计：
| 模式 | ISP 的体现 |
|---|---|
| Adapter | 适配器暴露客户端需要的窄接口，而非被适配者的全部 |
| Facade | 门面是按"客户端用途"裁剪的窄门面 |
| Proxy | 代理实现与真实主题相同的窄接口，不附加无关方法 |
| Strategy / State | 策略接口只含"算/迁移"一个行为，天然窄 |
| Composite | 叶子与容器的共享接口只含组合语义 |
反模式警示：如果你发现接口里躺着"只有部分实现者才用得上的方法"，多半是当初图省事把多个角色塞进了一个接口——该拆成 *able 风格的角色接口了。
一句话总结
接口隔离原则要求接口按客户端的使用视角切分，而不是按实现者的功能全集——客户端只依赖它真正用到的角色接口；接口变窄，传递依赖变少、空壳实现消失、每个客户端独立演进，与 SRP 一表一里地控制着系统边界的粒度。