接口隔离原则的核心是让每个接口只表达一类明确能力，需先拆解行为、识别职责边界再定义小而专的接口，如Swimmable、Flyable；实现类按需组合，避免哑方法和冗余依赖，接口粒度宜控制在3–5个内聚方法。
接口隔离原则的核心不是“少写接口”，而是让每个接口只表达一类明确的能力，避免把不相关的功能硬塞进同一个契约里。关键在于识别职责边界，再按需组合。
先拆解行为，再定义接口
不要一上来就设计“Animal”这种大而全的接口。先列出所有可能的行为，比如 eat、swim、fly、run、breathe、makeSound，然后观察哪些行为天然属于同一组——它们往往由同一类对象承担，且调用场景相近。
- 吃和叫，常出现在哺乳动物或鸟类日常交互中 → 可归入 Eatable 和 SoundProducer
- 游和呼吸（水下）常共现于鱼类 → Swimmable 和 AquaticBreather
- 飞和空中导航强相关 → 单独抽成 Flyable
让实现类只对接自己需要的能力
一个类该实现哪些接口，取决于它“能做什么”，而不是“它是什么”。比如：
-
Duck：既会游又会飞还会叫 → 实现
Swimmable、Flyable、SoundProducer -
Penguin：会游、会叫，但不会飞 → 实现
Swimmable、SoundProducer，不碰Flyable -
RobotCleaner：只会工作（move、sweep）→ 定义
Cleanable接口，不含任何生物行为
这样每个类没有“哑方法”（如 throw new UnsupportedOperationException()），也没有冗余依赖。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
用组合代替继承式“全能接口”
如果发现某个接口总被多个类“部分实现”，说明它已经超出了单一职责。这时应停用该接口，改为提供一组小接口，再通过组合方式复用能力。
- 错误做法：
interface Worker { void work(); void eat(); void sleep(); }→ Robot 不该有 eat/sleep - 正确做法：
interface Workable { void work(); }+interface Livable { void eat(); void sleep(); }→ Human 实现两个，Robot 只实现 Workable
注意接口粒度的“适度性”
接口不是越小越好，要兼顾可维护性和使用成本。比如把 void save() 和 void update() 拆成两个接口，反而增加调用方负担；但把 save()、sendEmail()、generateReport() 塞进同一个 Service 接口，就明显越界了。
- 判断标准：这些方法是否总是被同一调用者在同一流程中使用？是否共享状态或上下文？
- 经验参考：一个接口方法数建议控制在 3–5 个以内，且语义高度内聚
