当接口定义了固定参数的方法签名时，若某实现类需简化参数，不应强行忽略参数或滥用默认方法，而应重构接口契约，例如用 optional 封装可选参数，既保持接口统一性，又提升语义清晰度与扩展性。
当接口定义了固定参数的方法签名时，若某实现类需简化参数，不应强行忽略参数或滥用默认方法，而应重构接口契约，例如用 optional 封装可选参数，既保持接口统一性，又提升语义清晰度与扩展性。
在面向对象设计中，接口代表一种明确且不可妥协的契约。你当前的 DataAdapter 接口声明：
public interface DataAdapter {
int solve(int a, int b, int c);
}
这向所有实现者承诺：“调用方必须提供三个 int 参数，实现类必须能基于这三个值返回一个结果”。此时，若新增一个仅需 a 和 b 的实现（如 DataAdapterImplF），强行让其“忽略 c”（方案1）或在接口中新增 default solve(int, int) 方法（方案2），都会破坏契约一致性：
- ✅ 忽略参数（方案1）：虽能编译通过，但语义失真——接口声称需要 c，实现却无视它，调用方无法理解为何传入的 c 被静默丢弃，易引发误用和维护困惑；
- ❌ 新增 default 方法（方案2）：违反接口单一职责，使同一接口同时承担“三参数”和“两参数”两种语义，后续新增实现将面临方法选择歧义（该重写哪个？），也违背“接口应描述统一能力”的原则。
✅ 推荐方案：升级契约，显式表达可选性
将第三个参数建模为逻辑上可选，而非物理上强制。使用 Optional
public interface DataAdapter {
int solve(int a, int b, Optional<integer> c);
}</integer>
所有实现类均遵循同一方法签名，但可根据业务逻辑决定是否使用 c：
public class DataAdapterImplA implements DataAdapter {
@Override
public int solve(int a, int b, Optional<integer> c) {
// 仍要求 c 存在，否则抛异常或返回默认值
return c.orElseThrow(() -> new IllegalArgumentException("c is required"))
* a + b;
}
}
public class DataAdapterImplF implements DataAdapter {
@Override
public int solve(int a, int b, Optional<integer> c) {
// c 为 Optional.empty() 时直接忽略，仅用 a 和 b
return a * b; // 不依赖 c
}
}</integer></integer>
调用方代码也更清晰、安全：
DataAdapter adapter = new DataAdapterImplF(); int result = adapter.solve(2, 3, Optional.empty()); // 显式表明 c 不参与计算 int result2 = adapter.solve(2, 3, Optional.of(5)); // 若需传参，亦可灵活支持
⚠️ 注意事项与进阶建议
- 避免 null 代替 Optional：solve(int, int, Integer c) 中用 null 表示“未提供”虽可行，但丧失类型安全性，且易引发 NPE；Optional 是语义更严谨、API 更友好的选择；
- 考虑重载 vs. Optional：若 c 在绝大多数场景下都为空，也可将接口拆分为两个独立方法（如 solve(int, int) 和 solveWithC(int, int, int)），但会增加接口复杂度，适用于差异极大的场景；
-
向后兼容性：若该接口已被广泛使用，可先添加新方法（如 solveV2(int, int, Optional
)），并标注 @Deprecated 原方法，分阶段迁移，确保平滑演进。
总之，接口的演化不是妥协参数个数，而是精准表达领域语义。用 Optional 升级契约，既保持实现类的灵活性，又守护了接口作为公共协议的严肃性与可维护性。
