接口隔离原则关键在于按角色或能力垂直拆分，使实现类仅暴露必需方法，避免空实现和无意义依赖；需结合default方法渐进演进，并用依赖分析与测试验证解耦效果。

接口隔离原则落地不是拆得越碎越好，关键是让每个实现类只暴露它真正需要的方法，减少无意义的依赖和空实现。

从臃肿接口识别改造入口

当出现以下情况时，就是该动手拆接口的信号：

• 接口里有方法长期没人调用，但删又不敢删——怕影响其他模块
• 实现类中大量出现空方法体（{} ）或直接抛 UnsupportedOperationException
• 加一个新功能，要同步改接口、改多个实现类、再改所有调用方
• 写单元测试时，总得 mock 一堆根本用不到的方法

比如一个 Worker 接口同时定义了 work() 和 eat()，机器人实现类只能给 eat() 写个空方法——这就是典型的“被迫实现不相关能力”，必须拆。

按角色或能力垂直拆分，而非按模块切分

拆接口的核心逻辑是“谁用、用什么”，不是“这个功能归哪个包管”。每个小接口只表达一种明确的能力契约：

• Workable：只含 work() ——供机器人、人类、AI调度器等调用
• Eatable：只含 eat() ——仅人类、动物类实现
• Printable 和 Exportable 分开：报表服务只需打印，数据平台只需导出
• 订单系统中，UserOrderQuery、AdminOrderCRUD、PartnerOrderSync 各自独立，互不感知

注意：避免用继承拼凑小接口（如 AdvancedWorker extends Workable, Eatable），容易被父接口变更牵连；直接让具体类实现多个并列接口更稳定。

配合默认方法平滑演进

Java 8+ 支持接口中定义 default 方法，这对渐进式改造很关键：

• 新增能力时，先在目标小接口中加 default 方法，不破坏现有实现
• 老实现类可暂不重写，新实现类按需覆盖
• 后续逐步清理空实现或过时逻辑，完成自然过渡

例如在 Printable 中增加 default printWithHeader()，不影响已有打印机实现，又为后续扩展留出统一入口。

用依赖分析和测试验证隔离效果

拆完不是终点，要确认是否真降低了耦合：

• 检查调用方是否只引入了它实际用到的接口（比如 UI 层只依赖 UserOrderQuery，不依赖 AdminOrderCRUD）
• 运行单元测试，确认修改某个接口不会意外触发无关实现类的编译失败或行为变更
• 借助 IDE 的“Find Usages”或静态分析工具（如 ArchUnit），验证接口之间没有隐式强依赖

不复杂但容易忽略