Java接口要求实现类必须public重写所有抽象方法，default方法可选覆盖；多接口同名default需显式解决冲突；推荐接口+抽象基类封装共性逻辑，避免default污染契约；运行时应通过工厂或ServiceLoader解耦实现。
接口多实现类必须各自提供完整方法实现
Java 接口定义契约，不提供默认行为（除非是 default 或 static 方法），所以每个实现类都得用 public 显式重写所有抽象方法。哪怕两个实现逻辑高度相似，也不能靠“继承实现”来复用——接口不参与继承链，只被实现。
常见错误是忘记加 public 修饰符，导致编译报错：attempting to assign weaker access privileges；或者漏掉某个方法，提示 must override abstract method。
- 所有接口方法在实现类中必须是
public，不能是protected或包私有 - 若接口含
default方法，实现类可选择覆盖或直接使用，但不能省略抽象方法 - 多个接口含同名同签名方法时，实现类只需一个实现，但要注意语义一致性
用抽象类做共性逻辑提取，再让具体类实现接口
当多个实现类共享部分逻辑（比如日志、参数校验、模板流程），不要强行在接口里塞 default 方法——那会污染契约，且无法访问实例字段。更合理的方式是：定义接口 + 抽象基类实现共性 + 具体类继承并实现接口。
例如接口 PaymentProcessor，抽象类 AbstractPaymentProcessor 封装通用验签、幂等处理，而 AlipayProcessor 和 WechatProcessor 继承它并实现接口声明的方法。
- 抽象类可以有构造器、字段、
protected方法，适合封装状态和流程 - 接口仍负责定义能力边界（如
process()、refund()），保持松耦合 - 避免让抽象类实现接口后，又让子类“再次实现同一接口”——会造成冗余和歧义
注意 default 方法的冲突与覆盖规则
当一个类同时实现多个接口，且它们都提供了同签名的 default 方法，Java 编译器会拒绝编译，强制你显式覆盖该方法。这不是可选优化，而是必须解决的冲突。
例如接口
A 和 B 都有 default void log() { ... }，那么实现类 C 必须自己写一遍 public void log()，哪怕只是调用其中一个的 A.super.log()。
- 不能仅靠
extends父类来“继承” default 实现——接口 default 不参与类继承体系 -
default方法不能访问实现类的this字段（除非通过参数传入），作用域受限 - 过度依赖 default 方法会让接口逐渐变成“伪抽象类”，削弱其作为能力契约的意义
运行时选择实现类：用工厂或 ServiceLoader 解耦
接口多实现的价值，在于运行时按需切换行为。硬编码 new AlipayProcessor() 会锁死实现，应交由工厂或标准机制管理。
简单场景用静态工厂方法：PaymentProcessorFactory.getProcessor("alipay")；复杂系统可用 ServiceLoader 自动发现 META-INF/services/com.example.PaymentProcessor 下声明的实现类。
- 工厂类返回接口类型，调用方完全不感知具体实现
- ServiceLoader 要求实现类有无参构造器，且配置文件里写的是全限定类名
- Spring 等框架下，更推荐用
@Qualifier+ 接口注入，避免手动加载类
public interface PaymentProcessor {
String process(String orderId);
default void onInit() {
System.out.println("Initializing processor");
}
}
真正难的不是写出多个实现类，而是划清“接口定义权”和“实现决策权”的边界——前者归领域建模，后者归配置与运行时环境。一不留神，接口就会变成实现细节的集合。
