ISP核心是客户端不依赖未使用接口，需按需将胖接口拆为小而专的接口，如PowerControllable、Printable等，结合抽象类复用实现逻辑，命名体现能力而非角色，拆分依据是调用方和使用场景。
Java接口分离原则（Interface Segregation Principle，ISP）的核心就一句话：客户端不该依赖它用不到的接口。不是“能塞就塞”，而是“按需拆分”——把一个大而全的接口，拆成多个小而专的接口，让每个实现类只面对自己真正需要的方法。
为什么不能搞“胖接口”
比如定义一个 Device 接口，里面塞了 powerOn()、print()、playAudio()、scanDocument() 全部方法。结果打印机类必须实现 playAudio()，音响类又得硬写个空的 print()。这不是复用，是负担。
- 实现类被迫写一堆 throw new UnsupportedOperationException() 或空方法
- 接口语义模糊，看不出哪些方法属于同一职责
- 后续新增功能容易污染原有接口，影响所有实现类
怎么拆才合理
关键看行为是否属于同一上下文或使用场景。拆分后各接口职责清晰，彼此正交。
-
PowerControllable：只含powerOn()/powerOff() -
Printable：只含print(Document doc) -
Playable：只含play(AudioClip clip) - 一个多功能设备类可以同时实现多个接口，但普通台灯只需实现
PowerControllable就够了
和抽象类怎么配合
接口负责定义“能做什么”，抽象类负责解决“怎么做”的共性问题。
立即学习“Java免费学习笔记（深入）”；
- 比如所有带开关的设备都有
isPoweredOn状态和基础开关逻辑，可抽到AbstractPowerDevice中 - 具体类继承该抽象类 + 实现对应接口，既享受通用逻辑，又不被无关方法绑架
- 避免为了复用代码而在接口里加默认方法，把行为逻辑塞进接口会削弱其契约纯粹性
常见误判点
不是“只要方法多就要拆”，要看调用方是否真的混用。比如订单服务中 queryOrder() 和 cancelOrder() 虽然都在一个领域，但如果查询端和操作端完全隔离（前端不同模块、权限不同、部署不同），就值得拆成 OrderQueryService 和 OrderCommandService。
- 拆分依据是“谁在用”和“为什么用”，不是方法数量
- 接口名要体现能力（
Searchable、Exportable），而不是角色（AdminService） - 避免过度拆分：两个方法永远被同一组类一起实现，且语义紧密关联，就没必要硬拆
基本上就这些。接口不是越大越好，而是越准越好。拆得对，系统才松得开、改得稳、加得快。
