接口隔离原则（ISP）要求按角色而非功能点拆分接口，避免臃肿接口导致大量未使用方法、异常抛出或空返回；应通过渐进式迁移和角色化接口（如UserQuery/UserAdmin/UserSync）提升契约清晰度与可维护性。
接口隔离原则（ISP）不是教你怎么写接口，而是提醒你：别让一个接口变成“什么都要管”的万能工具箱。它直接针对那种实现类里一堆 throw new UnsupportedOperationException() 或者 return null 的尴尬场景——说明这个接口已经超出了它的实际使用范围。
识别臃肿接口的几个现实信号
不用等系统上线才发现问题，开发过程中就能观察到明显迹象：
- 某个接口的实现类里，超过三分之一的方法只是抛异常或返回空值
- 不同服务（比如订单模块、报表模块、通知模块）都实现同一个接口，但各自只用其中两三个方法，彼此调用路径完全不重叠
- IDE 显示大量 “Method is never used”，尤其集中在接口后半部分的方法上
- 写单元测试时，为了验证一个业务逻辑，不得不 mock 十几个方法，真正断言的只有 1–2 个
拆分接口要按“角色”而不是“功能点”
不是把所有方法简单切开就行，关键看谁在用、为什么用。比如一个原始的 UserOperation 接口，如果同时被前端页面、后台定时任务、第三方同步服务调用，那就该按角色拆：
-
UserQuery：只含findById、searchByName等只读方法，供前端和报表使用 -
UserAdmin：含disable、resetPassword，仅限管理员后台调用 -
UserSync：含exportToExternal、importFromJson，专供外部系统集成
这样每个实现类只关心自己那块职责，不会被无关方法干扰，也方便后续权限控制或灰度发布。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
立即学习“Java免费学习笔记（深入）”；
渐进式迁移比一刀切更稳妥
老系统里直接删掉大接口风险高，推荐三步走：
- 先定义新角色接口，并让新增代码优先依赖它们
- 在原接口中把即将废弃的方法标为
@Deprecated，并指向对应的新接口 - 等旧实现逐步替换完毕，再移除原接口——期间不影响任何线上功能
默认方法不是“免拆借口”的理由
Java 8+ 支持默认方法，有人觉得“加个默认实现就不用拆了”。其实这反而掩盖问题：默认方法让臃肿接口更容易被继续滥用，客户端依旧得导入整个接口，编译期依赖没减少，IDE 提示依然混乱，后期想抽离某块逻辑时更难下刀。ISP 关注的是契约的清晰度，不是实现的便利性。
