接口是行为契约，命名用名词或“able/ible”形式如Runnable，方法需单一职责、参数精简、返回抽象类型，慎用常量和默认方法，继承应符合语义一致性，优先组合而非过度继承。
接口在 Java 面向对象设计中，本质是行为契约，不是功能实现，而是明确“能做什么”的标准。规范定义接口，核心在于让接口真正起到统一约束、便于扩展、利于协作的作用。
命名要准确表达能力意图
接口名应使用名词或形容词+able/ible 形式，体现“可做某事”的能力，比如 Runnable、Comparable、Serializable。避免用 Manager、Helper 这类模糊词，也不建议加 I 前缀（如 IPayment），这不符合 Java 社区惯例。名称越贴近业务语义，越容易被理解与复用。
方法声明只保留必要抽象行为
接口中的抽象方法默认是 public abstract，无需显式写出；每个方法应：
- 有单一、明确的职责（例如 save() 和 validate() 不宜合并为 process()）
- 参数精简，避免过度重载
- 返回类型清晰，不返回具体实现类（优先用接口或基础类型）
- 不包含业务逻辑或状态操作（如不写 setRetryCount(int)，那是实现类的事）
常量和默认方法需谨慎使用
接口中允许定义常量，但仅限于全局通用、永不变更的配置值，例如：int MAX_RETRY = 3;
这类字段自动是 public static final，命名全大写加下划线。
默认方法（default）适合提供通用、非强制的辅助行为，比如集合接口中的 stream() 或 forEach()。但注意：
- 不要用默认方法替代核心抽象方法
- 避免在默认方法中访问实现类私有状态
- 若多个默认方法逻辑耦合，说明接口可能职责过重，应考虑拆分
继承与组合要服务于语义一致性
接口支持多继承（extends A, B, C），但仅当子接口确实是父接口能力的自然扩展时才用。例如：interface Flyable extends Movable, Audible 是合理的（飞行必然涉及移动与发声）；
而 interface User extends Reportable, Cacheable 就违背语义——报告能力和缓存能力不属于“用户”本身的固有行为。
更推荐的做法是：用组合方式表达能力关系，比如让类同时 implements User, Reportable，而不是强行拉通接口继承链。
