接口是行为契约的声明，定义组件交互规则。它强调“能做什么”而非“如何做”，通过抽象方法签名规范实现类行为，如PaymentService规定支付流程。遵循单一职责原则，拆分 AuthService 与 OrderService 可提升可维护性。Java 8 默认方法支持接口演进，新增 logTransaction 不破坏现有实现。依赖接口而非具体类实现解耦，便于单元测试中使用 Mock 对象验证逻辑。接口应视为模块间协作的协议文档，支撑高内聚、低耦合系统设计。
在Java中，接口不仅是语法结构，更是一种设计思想的体现。它定义了组件之间的交互规则，强调“能做什么”而不是“如何做”。理解接口规范与契约设计，是构建高内聚、低耦合系统的关键。
接口是行为契约的声明
Java中的接口本质上是一种契约（Contract），它规定了实现类必须提供的方法签名，但不涉及具体实现。这种分离使得调用方只依赖于抽象，而不关心背后的具体逻辑。
例如，一个支付系统可以定义如下接口：
public interface PaymentService {boolean process(double amount);
String getPaymentId();
}
任何实现该接口的服务——如支付宝、微信支付或银行卡支付——都必须遵守这个契约。调用方只需面向PaymentService编程，无需了解内部细节。
立即学习“Java免费学习笔记（深入）”；
接口设计应遵循职责单一原则
良好的接口设计要求每个接口只承担一个明确的角色。过于庞大的接口会导致实现类负担过重，也容易引发不必要的依赖。
比如，不要将用户认证和订单处理放在同一个接口中。应该拆分为：
-
AuthService：负责登录、登出、令牌生成 -
OrderService：负责下单、查询、取消订单
这样不仅提升了可维护性，也让单元测试更加清晰。
默认方法增强接口的演进能力
从Java 8开始，接口支持default方法，允许在不破坏现有实现的前提下扩展功能。
例如，在原有PaymentService中新增日志记录能力：
System.out.println("Processing payment: " + amount);
}
已有实现类无需修改即可使用此方法，同时保留了自行覆盖的自由度。这体现了接口作为契约的可演化性。
使用接口促进解耦与测试
通过依赖接口而非具体类，可以在运行时灵活替换实现。这一点在测试中尤为重要。
比如，在集成测试中使用真实支付服务，而在单元测试中注入模拟对象（Mock）：
@Testpublic void shouldCompleteOrderWhenPaymentSucceeds() {
PaymentService mockService = mock(PaymentService.class);
when(mockService.process(100.0)).thenReturn(true);
// 测试业务逻辑...
}
这种基于契约的测试方式，确保了代码对协议的遵循，而不受限于具体实现路径。
基本上就这些。接口不是为了写代码而存在，而是为了建立清晰、稳定、可扩展的协作规则。把接口当作团队间或模块间的“协议文档”来对待，才能真正发挥其价值。
