接口隔离原则要求每个接口只表达一种明确能力契约，按“谁用、用什么”垂直拆分，避免空方法和过度耦合，通过默认方法平滑演进，并用依赖检查验证隔离效果。
接口隔离原则（ISP）在接口设计中不是追求“拆得越多越好”，而是让每个接口只表达一种明确的能力契约，使实现类只暴露它真正需要的方法。
识别该拆的接口
当出现这些情况时，说明接口已经违背了ISP：
- 某个方法长期没人调用，但又不敢删——怕影响其他模块
- 实现类里写大量空方法体，或者直接抛 UnsupportedOperationException
- 新增一个功能，要改接口、改多个实现类、还要同步更新所有调用方
- 单元测试里总得 mock 一堆根本用不到的方法
比如一个 Worker 接口同时定义 work() 和 eat()，机器人实现时只能给 eat() 写个空方法——这就是典型的改造信号。
按能力或角色垂直拆分
不要按“模块”切，而要按“谁用、用什么”来切。每个接口只承载一类行为：
Java 接口排错助手
下载
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
- Workable：只含 work() ——供机器人、人类、AI调度器等调用
- Eatable：只含 eat() ——仅人类、动物类实现
- Printable 和 Exportable 分开：报表服务只需打印，数据平台只需导出
- 订单系统中：UserOrderQuery、AdminOrderCRUD、PartnerOrderSync 各自独立，互不感知
避免用继承拼凑小接口（如 AdvancedWorker extends Workable, Eatable），容易被父接口变更牵连；直接让具体类实现多个并列接口更稳妥。
用默认方法平滑演进
Java 8+ 的默认方法是过渡利器：
- 老接口已广泛使用？先不动它，把新能力抽成独立接口（如 Retryable）
- 必须扩展现有接口时，加 default 方法提供兼容实现，不强制所有实现类立刻响应
- 后续版本逐步引导迁移，比如日志中 warn 提示“XXX 接口的旧方法将在 v2.0 移除，请实现 Retryable”
验证是否真隔离了
拆完不是终点，得确认效果：
- 检查编译依赖：用户模块 jar 包里不该有 AdminOrderCRUD 类或相关 import
- 运行时扫描：用 ArchUnit 断言“UserService 不得依赖 Exportable 接口”
- 单元测试覆盖：每个接口的测试用例只覆盖本接口声明的方法，不越界
- 接口变更影响面明显收窄——改一个接口，不再连带几十个类报错
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
