当接口契约要求三个参数时，新增实现类若只需两个参数，不应强行忽略或重载方法，而应重构接口，用 Optional 将第三个参数显式标记为可选，既保持契约一致性，又提升类型安全与语义清晰度。
当接口契约要求三个参数时，新增实现类若只需两个参数，不应强行忽略或重载方法，而应重构接口，用 optional
在面向接口编程中，interface 的核心价值在于定义明确、稳定且具有一致语义的契约。原始接口 DataAdapter 声明了 int solve(int a, int b, int c) —— 这意味着所有实现类都必须接受且语义上依赖三个整型输入。此时若新增一个仅需 a 和 b 的实现（如 DataAdapterImplF），强行通过以下方式“绕过”契约将带来严重设计缺陷：
- ❌ 忽略第三个参数（如设为 0 或占位符）：破坏接口语义，调用方无法区分“c 未提供”和“c=0 是有效业务值”，易引发隐蔽逻辑错误；
- ❌ 在接口中添加 default 方法 solve(int a, int b)：违反单一职责与契约统一性——接口将同时承诺“三参数必填”和“两参数可选”，导致实现类行为不可预测，且现有调用方可能意外调用到默认实现，造成兼容性风险。
✅ 推荐方案：升级接口契约，使用 Optional<Integer> 显式表达可选性
public interface DataAdapter {
int solve(int a, int b, Optional<Integer> c);
}该设计具备三大优势：
- 语义清晰：Optional<Integer> 明确传达“c 是可选的”，而非隐式约定（如传 -1 或 0 表示无效）；
- 类型安全：编译器强制处理空值场景，避免 NullPointerException；
- 向后兼容（平滑迁移）：所有已有实现类只需微调方法签名，并在方法体内用 c.orElse(/** 默认值或抛异常 */) 处理缺失情况。例如：
public class DataAdapterImplA implements DataAdapter {
@Override
public int solve(int a, int b, Optional<Integer> c) {
// 保持原有逻辑：c 必须存在，否则抛异常或使用预设默认值
int cValue = c.orElseThrow(() -> new IllegalArgumentException("c is required for ImplA"));
return a + b + cValue; // 原有三参数逻辑
}
}
public class DataAdapterImplF implements DataAdapter {
@Override
public int solve(int a, int b, Optional<Integer> c) {
// c 可为空，仅用 a 和 b 计算
return a * b; // 无需 c 的专属逻辑
}
}⚠️ 注意事项：
- 避免滥用 Optional 作为方法返回值以外的参数（Java 官方指南建议），但作为入参表达“可选性”是合理且被广泛接受的实践（尤其在 API 设计中）；
- 若项目已广泛使用原始三参数接口且无法修改，可考虑引入新接口 DataAdapterV2 并逐步迁移，而非在原接口上打补丁；
- 调用方应主动构造 Optional：adapter.solve(1, 2, Optional.of(3)) 或 adapter.solve(1, 2, Optional.empty())，增强调用意图的可读性。
总结：接口不是模板，而是契约。当需求变化暴露原有契约粒度不足时，主动重构接口以精确表达业务语义，远胜于在实现层妥协契约——这正是面向对象设计中“里氏替换原则”与“接口隔离原则”的共同落脚点。
