接口隔离原则要求按行为职责拆解接口，使每个接口内聚（3–5个语义相关方法），类只实现真正需要的接口，避免哑方法；适配第三方组件时应封装最小契约，控制变更影响范围。
接口隔离原则不是把大接口“砍几刀”就完事，关键在于让每个接口只表达一类明确能力，让实现类只对接自己真正需要的行为。
先按行为职责拆解，再定义小而专的接口
别一上来就定义一个 Animal 接口囊括所有生物行为。先列出实际用到的操作，比如 swim、fly、run、makeSound、breathe，然后观察哪些行为天然成组：
- swim 和 underwaterBreathe 常共现于鱼类 → 抽成 Swimmable 和 AquaticBreather
- fly 和 navigateInAir 强相关 → 单独定义 Flyable
- makeSound 和 eat 属于日常交互高频组合 → 可归入 SoundProducer 和 Eatable
让类按需实现，不写哑方法
一个类该实现哪些接口，取决于它“能做什么”，而不是“它是什么”：
- Duck：会游、会飞、会叫 → 实现 Swimmable、Flyable、SoundProducer
- Penguin：会游、会叫，但不会飞 → 只实现 Swimmable、SoundProducer，完全不碰 Flyable
- RobotCleaner：只执行 sweep、move → 定义 Cleanable 接口，和生物行为零耦合
这样避免了 throw new UnsupportedOperationException() 这类占位式实现，也消除了编译期或运行时因误调用引发的隐患。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
控制接口粒度，3–5 个内聚方法为宜
接口不是越小越好，重点是内聚——方法之间有语义关联、调用场景相近、变更节奏一致：
- 把 queryOrder()、pay()、cancel() 放进 OrderPayment 接口，合理；混入 refund() 或 fetchReport() 就破坏内聚
- 退款流程专用的 RefundService，只保留 refund()、queryRefund()、retryRefund()，字段、错误码、重试策略都可独立演进
用适配器封装第三方组件，暴露最小契约
面对臃肿的 SDK 或业务组件，不要直接 implements 总接口：
- 用 IDE 的 “Find Usages” 或日志链路扫描，确认项目里真实调用的方法（比如只用了 init/pay/queryOrder）
- 新建 PaymentService 接口，仅声明这三个方法
- 写 AlipayAdapter，内部委托原始 SDK，对外只暴露 PaymentService
- 业务层依赖 PaymentService，完全感知不到 SDK 升级带来的签名变化或废弃方法
每次外部变动，影响范围被锁死在单个适配器内，系统健壮性来自可控，而非不变。
