接口隔离原则（ISP）落地关键在于按角色/能力垂直拆分接口，使实现类仅暴露必需方法，配合默认方法平滑演进，并通过依赖分析和测试验证隔离效果。
接口隔离原则（ISP）在Java系统设计中不是纸上谈兵，而是解决实际耦合痛点的实用工具。它的落地关键不在“要不要拆接口”，而在于“什么时候拆、怎么拆才真正降低维护成本”。核心就一条：让每个实现类只看到它必须实现的方法，其他一概不暴露。
从臃肿接口开始识别改造点
典型信号是出现以下任一情况：
- 某个接口里有方法长期没人调用，但又不敢删——怕影响其他模块
- 实现类里大量空方法体或抛 UnsupportedOperationException
- 新增一个功能，要改接口、改多个实现类、还要同步更新所有调用方
- 单元测试里总得 mock 一堆根本不用的方法
比如原始 Worker 接口同时定义 work() 和 eat()，机器人类只能写个空的 eat() 方法，这就是明确的改造入口。
按角色/能力维度垂直拆分接口
不要按“系统模块”切，而要按“谁用、用什么”来切。每个接口只表达一种能力契约：
立即学习“Java免费学习笔记（深入）”；
- Workable：仅含 work() —— 供机器人、人类、AI调度器等调用
- Eatable：仅含 eat() —— 只有人类、动物类实现
- Printable 和 Exportable 分开：报表服务只需打印，数据平台只需导出
- 订单系统中，UserOrderQuery、AdminOrderCRUD、PartnerOrderSync 各自独立，互不感知
注意：避免用继承方式拼凑小接口（如 AdvancedWorker extends Workable, Eatable），这容易导致子接口被父接口变更牵连；直接让具体类实现多个并列接口更稳妥。
配合默认方法控制演进节奏
Java 8+ 的默认方法是平滑过渡的好帮手：
- 老接口已广泛使用？先不动它，把新能力抽成独立接口（如 Retryable）
- 若必须扩展现有接口，可加 default 方法提供兼容实现，不强制所有实现类立刻响应
- 后续版本再逐步引导迁移，比如日志中 warn 提示“XXX 接口的旧方法将在 v2.0 移除，请实现 Retryable”
这样既守住了 ISP 原则，又没卡住上线节奏。
用测试和依赖分析验证效果
拆完不是终点，得确认是否真“隔离”了：
- 检查各模块的编译依赖：用户模块 jar 包里不该有 AdminOrderCRUD 类或 import
- 运行时扫描：用工具（如 ArchUnit）断言“UserService 不得依赖 Exportable 接口”
- 单元测试覆盖：每个接口的测试用例只覆盖本接口声明的方法，不越界
- 接口变更影响面明显收窄——改 Printable 不再触发导出服务的回归测试
真正落地的 ISP，是让开发人员自然地“只看到该看的”，而不是靠文档提醒“别用这个方法”。
