接口分离原则：简化接口，避免冗余定义

接口分离原则强调按调用方角色（而非功能模块）精简接口契约，避免因臃肿接口导致实现类被迫填充空方法或异常抛出、隐式耦合加剧及后续变更牵一发而动全身；当实现类超1/3方法未被使用时，便是明确的重构信号——应拆分为如LoginCapable、EmailCapable等聚焦单一职责的小接口，同时将该思想延伸至工具类、抽象类等所有被依赖的契约层面；但拆分需以真实、独立的调用方为依据，兼顾命名表意性与发布后的稳定性，宁可渐进保守，也不盲目求细，真正让接口成为清晰、灵活、低维护成本的协作边界。

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

这是最直观的信号：当你发现某个 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 个再反复合并

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。