java通过接口实现契约式编程，即用接口定义功能契约（能做什么），各模块仅依赖接口而非实现，实现类必须严格遵守方法签名与语义约定，配合依赖注入、工厂模式和契约测试保障解耦、可替换与行为一致性。
Java 通过接口实现模块间的契约式编程，核心在于用接口定义“能做什么”，而非“怎么做”。各模块只依赖接口，不依赖具体实现，从而解耦、可替换、易测试。
接口作为明确的契约
接口声明一组公开方法，规定调用方可以使用的功能、参数类型、返回值和异常。实现类必须满足这些约定，否则编译失败。这相当于在代码层面签署了一份“协议”：
- 调用方只关心接口方法签名，不关心内部逻辑
- 提供方承诺实现全部接口方法，且行为符合文档或约定语义（如
List.add()必须添加元素、Map.get()对 null key 的处理） - 违反契约（如空指针不抛预期异常、返回值不符合文档说明）属于实现缺陷，不是接口问题
模块间通过接口通信
不同模块（如订单服务、支付服务、通知服务）各自定义面向对方的接口，而非直接引用对方的实现类：
- 订单模块定义
PaymentService接口（含pay(Order order)），由支付模块实现 - 支付模块定义
NotificationService接口（含send(String content)），由通知模块实现 - 各模块通过依赖注入（如 Spring 的
@Autowired PaymentService）获取接口实例，运行时绑定具体实现 - 模块升级或替换（如从短信通知换成邮件通知）只需提供新实现，不修改订单/支付模块代码
配合抽象工厂或策略模式增强灵活性
当一个接口有多个实现且需动态选择时，可用工厂封装创建逻辑，进一步隐藏实现细节：
- 定义
DiscountStrategy接口，有calculate(double amount)方法 - 实现
MemberDiscount、SeasonalDiscount、FixedDiscount - 提供
DiscountStrategyFactory，根据订单类型或用户等级返回对应策略实例 - 业务模块只依赖
DiscountStrategy接口和工厂，无需 if-else 判断具体类型
配合单元测试验证契约一致性
针对接口编写通用测试套件，确保所有实现都遵守同一契约：
- 写一个
PaymentServiceContractTest，测试pay()在金额为负时是否抛IllegalArgumentException - 让
AlipayServiceTest和WechatPayServiceTest都继承它 - 只要新增支付实现，跑一遍契约测试，就能快速发现是否破坏了统一行为规范
契约式编程不是靠文档或口头约定，而是靠编译检查 + 接口设计 + 测试覆盖共同保障。接口是模块之间的“法律条文”，实现是“履约行为”，而测试就是“执法监督”。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
