接口隔离原则要求每个接口只表达一类明确能力，按行为维度拆分为小而精的接口（如FlightCapable、Swimmable），方法少而聚焦，面向调用方定制，避免过度拆分或命名泛化。
接口隔离原则的核心是让每个接口只表达一类明确的能力，避免把不相关的功能塞进同一个接口里。它不是追求接口数量越多越好，而是让依赖更精准、实现更轻量。
按行为维度拆分接口
把原本混杂在单个接口里的不同职责，按实际能力归类成多个小接口。比如“能飞”“能游”“能吃”这些动作，分别定义为 FlightCapable、Swimmable、Eatable，而不是全堆在 Animal 一个接口里。
- 鱼只需实现 Eatable 和 Swimmable，不用管飞行相关方法
- 狗实现 Eatable 和 Walkable，完全避开 FlightCapable
- 鸟可组合实现 Eatable、FlightCapable，按需叠加
控制接口方法粒度和数量
每个接口公开的方法要少而精，只保留该能力下真正必要的契约。一个接口里有 5 个方法，但某个实现类只用其中 2 个，就说明接口还不够细。
- 避免像 Repair 接口同时声明
repairCar()、repairTrain()、repairPlane()—— 不同维修场景的调用方根本不需要全部能力 - 改为 CarRepairable、TrainRepairable、PlaneRepairable，让 4S 店只依赖自己用得上的那个
- 方法命名也要聚焦，比如
antiTheft()比securityAction()更具体、边界更清晰
面向调用方定制接口
不是从实现类出发去“凑接口”，而是先看谁在用、怎么用。同一个实体，在不同上下文中暴露的能力可能完全不同。
- 门在校园场景需要防盗 + 防火 + 防水，就实现三个对应接口
- 家庭安防门只要防盗 + 防火，就不必绑定防水能力
- 客户端代码（如 ClientTest）只看到自己关心的接口，不会被无关方法干扰或强制实现
警惕过度拆分和命名泛化
接口太小会带来大量空接口或组合爆炸；名字太宽泛又失去约束力。关键看是否真实反映一种稳定、可复用的行为契约。
- 不要把
setX()和getX()单独拆成两个接口，它们天然属于同一职责 - 避免出现 BasicOperation、CommonInterface 这类模糊命名，无法传达意图
- 当多个小接口经常被同一类一起实现时，可以反问：它们是否本就属于同一抽象层次？是否需要更高层的聚合（如标记接口或默认方法）？
接口是系统对外的承诺，不是实现的草稿纸。设计时多想一步“谁会用它”“它代表什么能力”，比堆方法更重要。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
