接口契约通过定义行为规范实现解耦，提升系统可维护性与扩展性。①接口仅声明方法签名，体现“能做什么”而非“怎么做”，如PaymentProcessor规定支付能力；②面向接口编程使依赖抽象，OrderService依赖PaymentProcessor接口，更换实现无需修改代码；③接口应遵循单一职责，避免混杂无关行为，如支付与日志应分离；④Java 8支持default和static方法，可安全扩展功能而不破坏现有实现；⑤接口一旦发布需谨慎修改，优先新增或使用默认方法演进。核心是约定优于实现，坚持高内聚、低耦合。
接口契约在Java中是一种规范化的约定，它定义了类与类之间交互的行为规则。理解接口契约，本质上是理解“能做什么”而非“怎么做”。Java中的接口（interface）正是实现这种契约的核心机制。通过接口，设计者可以明确服务提供方应具备的能力，同时让调用方基于统一的抽象进行编程，从而提升系统的可维护性与扩展性。
接口体现行为契约
接口不包含实现细节，只声明方法签名，这使得它成为纯粹的行为契约。任何实现该接口的类都必须遵守这一契约，提供对应的方法实现。
例如，定义一个PaymentProcessor接口：
public interface PaymentProcessor {
boolean processPayment(double amount);
String getPaymentMethod();
}
不同的支付方式如支付宝、银行卡等都可以实现这个接口，各自提供逻辑。调用方无需关心具体实现，只需依赖接口编程，只要对象符合契约，就能正常使用。
立即学习“Java免费学习笔记（深入）”；
面向接口编程降低耦合
设计原则中强调“依赖于抽象，而不是具体实现”。使用接口作为方法参数、返回类型或成员变量类型，可以让代码对具体类的依赖降到最低。
比如服务类中持有接口引用：
public class OrderService {
private PaymentProcessor processor;
public OrderService(PaymentProcessor processor) {
this.processor = processor;
}
public void checkout(double amount) {
if (processor.processPayment(amount)) {
System.out.println("支付成功");
}
}
}
这样更换支付方式时，不需要修改OrderService，只需传入新的实现即可，系统更灵活，易于测试和扩展。
接口设计应遵循单一职责
一个接口应该只定义一组相关的行为。如果接口承担过多职责，会导致实现类被迫实现不需要的方法，违背设计初衷。
例如，不要将支付和日志记录放在同一个接口中。可以拆分为：
- PaymentProcessor：处理支付逻辑
- Logger：负责记录操作日志
每个接口专注一件事，实现类也更清晰，便于复用和管理。
合理使用默认方法与静态方法
Java 8之后，接口可以包含default方法和static方法，这为接口契约提供了更大的灵活性。
默认方法允许在不破坏已有实现的前提下扩展接口功能：
public interface PaymentProcessor {
boolean processPayment(double amount);
String getPaymentMethod();
default void logTransaction(String id) {
System.out.println("交易记录: " + id);
}
}
实现类可选择覆盖该方法，也可直接使用默认实现。静态方法则可用于工具性质的操作，如创建常用实例或校验参数。
基本上就这些。接口契约的核心在于“约定优于实现”，通过清晰的责任划分和抽象设计，使系统更具弹性。在实际开发中，结合业务场景合理定义接口，坚持高内聚、低耦合的原则，才能真正发挥接口的价值。不复杂但容易忽略的是：接口一旦发布，修改需谨慎，尽量通过新增接口或默认方法来演进，避免破坏现有实现。
