接口解决依赖倒置与多实现切换问题，本质是定义能力契约，只声明必须实现的行为，不包含状态、非核心方法或冗余逻辑；命名需体现业务意图，拆分遵循单一职责，演进须谨慎。

接口解决了“依赖倒置”和“多实现切换”问题

Java 接口本质是契约，不是实现。它让调用方（如服务类）只依赖抽象 PaymentProcessor，而不绑定具体 AlipayProcessor 或 WechatPayProcessor。这样更换支付渠道时，只要新类实现同一接口，上层代码完全不用改——这是解耦的核心价值。

常见错误是把接口当工具类用，比如定义一堆静态方法在接口里（Java 8+虽支持 static 方法，

但语义上违背接口初衷），结果导致调用方又和具体逻辑耦合了。

• 接口中只放公开的、必须被实现的行为声明（void pay(BigDecimal amount)）
• 不放状态字段（private String token 是错的）
• 避免为“方便”而塞进与核心契约无关的方法（比如 logTransaction() 如果不是所有实现都必须做，就不该出现在接口里）

接口 vs 抽象类：选谁取决于“要不要共享状态或默认行为”

如果多个实现需要共用字段（如 retryCount）、构造逻辑或部分通用方法（如 validateInput()），抽象类更合适；如果只是“它们都能做 X”，且彼此状态隔离、行为差异大，就用接口。

Java 8 后接口可带 default 方法，但别滥用：一个 default 方法若内部依赖未声明的字段，或逻辑复杂到需要测试，说明它本该属于抽象基类。

• 接口适合定义能力（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），旧接口保留，通过适配器桥接。强行在原接口加方法，往往意味着你当初没想清能力边界。

真正难的不是写接口，是判断哪些行为属于“所有实现必然具备”，哪些只是“当前多数实现碰巧都有”。这个判断错了，后续所有重构成本都会翻倍。