接口隔离原则要求接口职责单一、内聚且按客户端需求定制，避免臃肿或过度拆分；应依据业务语义将同类操作归一、跨域行为分离，并通过正交小接口组合能力，兼顾粒度与环境适配。

接口隔离原则（ISP）的核心，是让接口变“瘦”——不是塞进所有功能，而是只保留某类行为的最小集合。它不追求接口数量最多，而追求每个接口职责清晰、调用方用得安心。

接口要小，但不能碎

小接口 ≠ 零散方法堆砌。比如把 save() 和 update() 拆成两个接口，反而增加使用成本；但把 save()、sendEmail()、generateReport() 塞进同一个 UserService 接口，就明显越界了。关键看业务语义是否内聚：

• 同一类操作（如增删改查）可归入一个接口，如 Crudable
• 跨领域行为（如发邮件、记日志、生成报表）应独立抽离
• 拆分后，各实现类不再被迫实现空方法或抛 UnsupportedOperationException

按客户端需求定制接口

不是“开发者觉得该有啥”，而是“谁用、用在哪、需要啥”。例如：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• 机器人类 Robot 只需 Workable（含 work()），不该被要求实现 eat() 或 sleep()
• 人类类 Human 才同时实现 Workable 和 Livable
• 门控系统中，学校门需防盗+防火+防水，家庭门只需防盗+防火——分别组合 AntiTheft、Fireproof、Waterproof 即可

组合优于继承式“全能接口”

当发现多个类都只实现某个大接口的一部分方法，就是拆分信号。此时应停用原接口，转为提供一组正交的小接口，再通过类的多重实现来组合能力：

立即学习“Java免费学习笔记（深入）”；

• 避免：interface Worker { work(); eat(); sleep(); }
• 推荐：interface Workable { work(); } + interface Livable { eat(); sleep(); }
• 类按需实现，不强绑无关行为，也便于未来替换（如用 AIWorker 替换 Human，只需重用 Workable）

注意粒度平衡与环境适配

接口太粗，耦合高；太细，管理难。判断标准来自实际场景：

• 团队规模小、迭代快：接口可稍宽，减少初期设计成本
• 模块多、依赖广、需长期维护：优先按子域拆分，如 UserQueryService 和 UserCommandService 分离读写
• 对外 SDK 或跨系统契约：接口越稳定越专一，避免因内部调整导致下游被动升级