接口隔离原则要求每个接口只表达一种明确能力契约，按“谁用、用什么”垂直拆分，避免空方法和过度耦合，通过默认方法平滑演进，并用依赖检查验证隔离效果。

接口隔离原则（ISP）在接口设计中不是追求“拆得越多越好”，而是让每个接口只表达一种明确的能力契约，使实现类只暴露它真正需要的方法。

识别该拆的接口

当出现这些情况时，说明接口已经违背了ISP：

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

比如一个 Worker 接口同时定义 work() 和 eat()，机器人实现时只能给 eat() 写个空方法——这就是典型的改造信号。

按能力或角色垂直拆分

不要按“模块”切，而要按“谁用、用什么”来切。每个接口只承载一类行为：

Java 接口排错助手

在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。

下载

立即学习“Java免费学习笔记（深入）”；

• 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 接口”
• 单元测试覆盖：每个接口的测试用例只覆盖本接口声明的方法，不越界
• 接口变更影响面明显收窄——改一个接口，不再连带几十个类报错