接口精简，遵循Java分离原则

本文深入探讨了Java开发中接口分离原则（ISP）的实践精髓，强调接口应围绕调用方角色（如Web控制器、通知服务、分析任务）而非功能模块进行精简拆分，避免出现大量空实现或UnsupportedOperationException；指出当实现类超1/3方法未被使用时即为重构明确信号，并延伸至工具类、抽象类等广义“契约”的污染治理，同时提醒警惕过度拆分，主张以真实、独立的调用场景为边界，用清晰的角色命名（如LoginCapable、OrderPlacer）构建高内聚、低耦合、易演进的API体系——这不仅是代码整洁之道，更是守护系统长期可维护性的关键防线。

接口太大，实现类就得写一堆空方法

这是最直观的信号：当你发现某个 interface 里有 8 个方法，但具体实现类（比如 PaymentService）只用其中 2 个，另外 6 个只能写成 throw new UnsupportedOperationException() 或空实现——说明这个接口已经违反了接口分离原则。

根本原因不是“多写了代码”，而是耦合被悄悄埋下了：一旦某天有人在那个臃肿接口里加第 9 个方法，所有实现类都得改，哪怕它们完全不碰这个新功能。

• 典型场景：早期定义一个 UserOperation 接口，塞进 login()、logout()、sendEmail()、generateReport()、syncToCRM()……结果后台定时任务模块只调 syncToCRM()，却被迫实现其余四个
• 判断标准：如果一个类实现接口后，有超过 1/3 的方法体是空的或抛异常，就该拆
• 不要等“重构时机”，这种接口越早拆，后续新增模块越不容易误引依赖

怎么拆？按调用方角色来分，不是按功能模块

很多人误以为“把用户相关方法放一起”就是合理拆分，结果还是得到一个“UserAllInOne”接口。真正有效的拆法，是看谁在用、怎么用。

比如同一个用户系统，可能有三个调用方：WebController（需要登录/登出）、NotificationService（只需要发邮件）、AnalyticsJob（只需要生成报表）。它们之间没有交集，也不该知道彼此的存在。

• 正确做法：定义三个接口 —— 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 个再反复合并

理论要掌握，实操不能落！以上关于《接口精简，遵循Java分离原则》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！