接口应按调用方角色而非功能模块拆分，如logincapable、emailcapable、reportcapable；若实现类超1/3方法为空或抛异常，即违反接口分离原则，需及时重构。
接口太大，实现类就得写一堆空方法
这是最直观的信号：当你发现某个 interface 里有 8 个方法，但具体实现类（比如 PaymentService）只用其中 2 个，另外 6 个只能写成 throw new UnsupportedOperationException() 或空实现——说明这个接口已经违反了接口分离原则。
根本原因不是“多写了代码”，而是耦合被悄悄埋下了：一旦某天有人在那个臃肿接口里加第 9 个方法，所有实现类都得改，哪怕它们完全不碰这个新功能。
- 典型场景：早期定义一个
UserOperation接口，塞进login()、logout()、sendEmail()、generateReport()、syncToCRM()……结果后台定时任务模块只调syncToCRM()，却被迫实现其余四个 - 判断标准：如果一个类实现接口后，有超过 1/3 的方法体是空的或抛异常，就该拆
- 不要等“重构时机”，这种接口越早拆，后续新增模块越不容易误引依赖
怎么拆？按调用方角色来分，不是按功能模块
很多人误以为“把用户相关方法放一起”就是合理拆分，结果还是得到一个“UserAllInOne”接口。真正有效的拆法，是看谁在用、怎么用。
比如同一个用户系统，可能有三个调用方：WebController（需要登录/登出）、NotificationService（只需要发邮件）、AnalyticsJob（只需要生成报表）。它们之间没有交集，也不该知道彼此的存在。
立即学习“Java免费学习笔记（深入）”；
- 正确做法：定义三个接口 ——
LoginCapable、EmailCapable、ReportCapable，各自只含 1–2 个方法 - 错误做法：拆成
UserAuthInterface+UserNotifyInterface，但每个接口仍包含 init()/close()/validate() 等通用方法——这些其实是基础设施，不该混在业务契约里 - Java 中可以多实现：
class WebUserController implements LoginCapable, LogoutCapable，比继承一个大接口更灵活
interface 不是唯一要隔离的东西，类和抽象类也适用
很多人只盯着 interface 关键字，忘了 ISP 的“接口”是广义的——任何被其他模块依赖的契约，都算。
比如你写了一个工具类 FileUtils，对外暴露了 readText()、writeJson()、compressZip()、encryptAes()、uploadToOSS()……而某个业务模块只调 readText()，但它却得引入整个 commons-io + fastjson + aliyun-oss-sdk 依赖。这就是类层面的接口污染。
- 解决方式：把
FileUtils拆成TextReader、JsonWriter、ZipCompressor等小类，或者提供静态工厂方法按需加载 - 注意：抽象类同理，如果子类只重写其中一两个模板方法，其余全空实现，那这个抽象类就该被质疑
- IDE 提示很诚实：IntelliJ 在实现接口时，如果弹出“Implement all methods”警告，且你发现其中有明显无关的方法，就是拆分信号
别为了“小”而过度拆，一个接口至少要有稳定调用方
拆接口不是越细越好。如果定义了 CanClickButton、CanHoverButton、CanFocusButton 这种粒度，反而让使用者困惑：到底该依赖哪个？有没有遗漏？
关键判断点在于——是否存在真实存在的、独立演化的调用方。没有实际使用场景的“最小接口”，只是制造了更多维护负担。
- 安全边界：一个接口至少被 2 个以上不共享上下文的类实现，或被 2 个以上不同模块 import，才值得单独存在
- 命名要反映角色，而不是动作：
OrderPlacer比PlaceOrderCapable更清晰；InventoryChecker比CheckStockMethod更易理解 - 最容易被忽略的一点：接口一旦发布（尤其作为 SDK 或内部公共包），修改成本远高于类——所以宁可先保守拆成 2–3 个，也不要一步到位拆成 10 个再反复合并
