接口解决依赖倒置与多实现切换问题，本质是定义能力契约，只声明必须实现的行为，不包含状态、非核心方法或冗余逻辑；命名需体现业务意图，拆分遵循单一职责，演进须谨慎。
接口解决了“依赖倒置”和“多实现切换”问题
Java 接口本质是契约，不是实现。它让调用方（如服务类）只依赖抽象 PaymentProcessor，而不绑定具体 AlipayProcessor 或 WechatPayProcessor。这样更换支付渠道时，只要新类实现同一接口，上层代码完全不用改——这是解耦的核心价值。
常见错误是把接口当工具类用，比如定义一堆静态方法在接口里（Java 8+虽支持 static 方法，但语义上违背接口初衷），结果导致调用方又和具体逻辑耦合了。
- 接口中只放公开的、必须被实现的行为声明（
void pay(BigDecimal amount)） - 不放状态字段（
private String token是错的） - 避免为“方便”而塞进与核心契约无关的方法（比如
logTransaction()如果不是所有实现都必须做，就不该出现在接口里）
接口 vs 抽象类：选谁取决于“要不要共享状态或默认行为”
如果多个实现需要共用字段（如 retryCount）、构造逻辑或部分通用方法（如 validateInput()），抽象类更合适；如果只是“它们都能做 X”，且彼此状态隔离、行为差异大，就用接口。
Java 8 后接口可带 default 方法，但别滥用：一个 default 方法若内部依赖未声明的字段，或逻辑复杂到需要测试，说明它本该属于抽象基类。
立即学习“Java免费学习笔记（深入）”；
- 接口适合定义能力（
Runnable、Comparable） - 抽象类适合定义“是什么”+“怎么起步”（
AbstractList提供size()、isEmpty()基础实现） - 一个类可以实现多个接口，但只能继承一个抽象类——这点直接影响架构扩展性
接口命名和方法设计暴露真实业务意图
接口名不是 IPaymentService（I前缀冗余，且 Service 模糊），而是 PaymentGateway；方法名不是 doPay()，而是 submitPayment()。名字要让人一眼看出“谁在什么场景下用它达成什么结果”。
容易踩的坑是把接口做成“万能胶”：加个 refund()，再加个 queryStatus()，最后变成所有支付相关操作的大杂烩。这违反单一职责，也导致实现类被迫抛 UnsupportedOperationException。
- 按业务动作边界拆分接口，比如
PaymentInitiator和PaymentRefunder - 方法参数尽量用不可变对象或值对象（
PaymentRequest），别传Map - 返回类型明确失败语义：用
Optional或自定义Result，而不是靠null或异常传递业务失败
接口的演进比实现类更敏感，版本控制必须谨慎
一旦发布接口（尤其被外部系统或模块依赖），添加方法就是破坏性变更——老实现类编译不过。Java 8 的 default 方法能缓解，但仅限于真正通用、无副作用的补充逻辑（比如加个 isSupportedCurrency(String code) 默认返回 true）。
更安全的做法是定义新接口（PaymentGatewayV2），旧接口保留，通过适配器桥接。强行在原接口加方法，往往意味着你当初没想清能力边界。
真正难的不是写接口，是判断哪些行为属于“所有实现必然具备”，哪些只是“当前多数实现碰巧都有”。这个判断错了，后续所有重构成本都会翻倍。
