java接口定义业务行为契约，只声明“做什么”不关心“怎么做”，聚焦单一稳定语义，支持default和static方法增强表达力，可通过extends组合能力，配合注解与文档明确意图。
Java中用interface定义业务行为契约，核心是**只声明“做什么”，不关心“怎么做”**。它不是模板或父类，而是对一类对象能力的抽象约定——比如“能支付”“能审核”“能导出”，这些能力可被不同业务实体独立实现，又能在统一接口下被调用。
用interface明确业务能力边界
接口应聚焦单一、稳定的业务语义，名称体现职责（如PaymentProcessor、ApprovalRule），避免泛化（如BusinessService）。方法签名只写访问修饰符public（可省略）、返回类型、方法名和参数列表，不写方法体，也不允许有实例字段。
- ✅ 正确示例：
boolean processPayment(BigDecimal amount, String orderId); - ❌ 错误做法：在接口里写
private String logPrefix = "PAY-";或public void processPayment(...) { ... }
利用默认方法与静态方法增强契约表达力
从Java 8起，接口可含default方法（提供通用实现）和static方法（工具逻辑），它们不破坏契约本质，反而让接口更自洽。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
-
default适合共性逻辑：如validateAmount()校验金额为正，所有实现类自动获得，无需重复写 -
static适合无状态工具：如formatReceiptId(String raw)，调用方直接通过接口名访问，不依赖实例 - 注意：
default方法不能访问实现类的私有成员，仅能调用本接口其他default或static方法
用extends组合多个契约，构建复合业务能力
一个业务角色常需多种能力，例如“风控专员”既要审核又要生成报告。此时让接口继承多个接口，比在类中硬编码多个实现更清晰：
interface RiskOfficer extends ApprovalPolicy, ReportGenerator, AlertNotifier- 实现类只需
implements RiskOfficer，即承诺支持全部能力 - 避免“胖接口”：若某子接口方法对多数实现无意义（如
printToPaper()对纯API服务），应拆分
配合注解与文档强化契约意图
接口本身不运行，但它是协作的基础。用@FunctionalInterface标记单抽象方法接口（如Function<order boolean></order>），便于Lambda适配；在Javadoc中说明每个方法的业务前提、成功条件和异常场景（如“当订单状态非‘待审’时抛出IllegalStateException”）。
- 关键点：契约失效往往源于理解偏差，而非语法错误
- 建议在接口顶部用
@since注明版本，@deprecated标记过期方法并指明替代方案
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
