接口隔离原则（Interface Segregation Principle, ISP）是面向对象设计的五大 SOLID 原则之一，核心思想是：客户端不应该被迫依赖它不需要的接口。换句话说，一个类对另一个类的依赖应该建立在最小的接口上，避免“胖接口”导致的冗余依赖和耦合。
一、为什么需要接口隔离原则？
想象一个场景：你定义了一个Animal接口，包含fly()（飞）、swim()（游泳）、run()（跑）三个方法。然后让Dog（狗）实现这个接口——但狗不会飞，fly()方法对狗来说就是“无用且强制”的依赖。此时：
狗的实现类不得不为空实现
fly()（或抛异常），造成代码冗余；若后续修改
fly()方法的逻辑，所有实现类（包括狗）都要重新编译/测试，哪怕它们根本不用这个方法；客户端调用
animal.fly()时，可能误以为狗能飞，引发逻辑错误。
这就是“胖接口”的问题：接口中包含客户端不需要的方法，导致依赖冗余和潜在错误。接口隔离原则就是为了解决这个问题——将大接口拆分成更小、更具体的接口，让客户端只依赖自己需要的接口。
二、核心定义与内涵
ISP 的经典表述来自 Robert C. Martin：
Clients should not be forced to depend on methods they do not use.（客户端不应被迫依赖它不使用的方法。）
其本质是“接口的粒度要适配客户端的需要”，具体包含两层含义：
接口要小而专：一个接口只负责一类功能（单一职责原则的延伸），避免“多功能混杂”；
避免“强迫依赖”：客户端只需知道与自己相关的接口，无需了解无关方法的存在。
三、违反 ISP 的典型案例
用一个常见的“打印机”例子说明：
1. 违反 ISP 的设计
定义一个IMachine接口，包含打印、扫描、传真三个方法：
// 胖接口：包含多个不相关功能 public interface IMachine { void print(); void scan(); void fax(); } // 老式打印机：只能打印，不会扫描和传真 public class OldPrinter implements IMachine { @Override public void print() { System.out.println("打印中..."); } // 被迫空实现（冗余） @Override public void scan() { throw new UnsupportedOperationException("不支持扫描"); } // 被迫空实现（冗余） @Override public void fax() { throw new UnsupportedOperationException("不支持传真"); } }问题分析：
OldPrinter被迫实现了不需要的scan()和fax()，代码冗余且易出错（若调用这两个方法会抛异常）；若后续新增“仅扫描的设备”（如扫描仪），仍需实现
print()和fax()，同样冗余；客户端依赖
IMachine时，无法明确设备的具体能力，可能误调用。
2. 符合 ISP 的改进
将IMachine拆分为更小的专用接口，让设备按需实现：
// 拆分后的小接口：职责单一 public interface IPrinter { void print(); } public interface IScanner { void scan(); } public interface IFax { void fax(); } // 老式打印机：只依赖 IPrinter public class OldPrinter implements IPrinter { @Override public void print() { System.out.println("打印中..."); } } // 多功能一体机：按需组合接口 public class MultifunctionMachine implements IPrinter, IScanner, IFax { @Override public void print() { /* ... */ } @Override public void scan() { /* ... */ } @Override public void fax() { /* ... */ } } // 仅扫描仪：只依赖 IScanner public class Scanner implements IScanner { @Override public void scan() { /* ... */ } }改进效果：
每个接口职责单一，
OldPrinter无需实现无关方法，消除冗余；客户端可按需依赖接口（如调用打印功能时，只需依赖
IPrinter），逻辑更清晰；新增设备时，只需实现对应接口，扩展更灵活。
四、如何实践接口隔离原则？
识别“胖接口”：检查接口中是否存在“部分实现类不需要的方法”，或客户端仅需其中少数方法的情况；
按“职责”拆分接口：根据功能的关联性拆分接口（如“打印”“扫描”“传真”是不同职责），确保每个接口只包含一组高度相关的方法；
避免“标记接口”：不要定义无任何方法的空接口（如
MarkerInterface）作为“分类标签”，这会导致客户端无意义地依赖；优先“角色接口”而非“类接口”：从“客户端需要什么功能”出发定义接口（即“角色接口”），而非从“某个类的所有能力”出发（即“类接口”）。
五、与其他 SOLID 原则的关系
单一职责原则（SRP）：SRP 关注“类的职责单一”，ISP 关注“接口的职责单一”，二者相辅相成——类的职责单一往往依赖接口的粒度合理；
依赖倒置原则（DIP）：DIP 要求“依赖抽象而非具体”，而 ISP 确保抽象的接口足够“小”，避免依赖冗余，是 DIP 的基础；
里氏替换原则（LSP）：若接口包含子类不需要的方法，子类可能无法完全替换父类（如
OldPrinter无法安全替换IMachine），违反 LSP，因此 ISP 是 LSP 的保障。
六、总结
接口隔离原则的核心是“小而专的接口，精准的依赖”。它提醒我们：接口不是“功能的堆砌”，而是“客户端与实现类之间的契约”——契约越精准，系统的耦合越低、扩展性越强。
正如 Robert C. Martin 所说：“接口隔离原则的本质是‘高内聚、低耦合’在接口层面的体现。” 拆分接口的过程，其实是在梳理系统的“职责边界”，让代码更易维护、更易理解。
