接口定义跨模块契约，抽象类封装内部复用骨架，组合使用须遵循单继承多实现；修改需严守兼容性红线，javadoc必须明确职责与约束。
团队架构设计规范里，接口与抽象类不是语法选择题，而是协作契约的制定方式。关键不在“能不能用”，而在“谁负责什么、边界划在哪”。
接口定对外能力边界，强制解耦
所有跨模块、跨团队调用的入口，必须用接口声明：
- 比如日志、配置、消息发送、规则引擎等通用能力，统一定义
ILogger、IConfigSource、IMessagePublisher - 接口方法只暴露必要参数和返回值，禁止带实现细节（如 HTTP 状态码、序列化格式）
- 新增方法优先加
default，但仅限无状态逻辑（如空值检查、基础转换），不许在 default 方法里访问成员变量或调用外部服务 - 每个接口职责单一，方法数控制在 3–7 个；超过需拆分（如把
IDataService拆为IReadable和IWritable）
抽象类管内部复用骨架，约束初始化流程
当多个实现类共享相同结构、状态或初始化逻辑时，才引入抽象类：
- 抽象类必须有明确命名后缀，如
AbstractHttpClient、BaseReportGenerator，避免模糊叫法（如CommonService） - 构造器强制传入关键依赖（如
Config、ExecutorService），确保实例化即可用 - 提供
final模板方法封装固定流程（如“校验→执行→记录→清理”），把可变步骤留作abstract方法 - 禁止在抽象类中定义 public static 工具方法——这类代码应归入独立工具类
组合使用是标准范式，不是可选项
真实 SDK 或核心模块的实现类，应严格遵循“单继承 + 多实现”结构：
- 写法唯一：
class OrderService extends AbstractTransactionalService implements AsyncCapable, Retryable, Tracable - 每个接口代表一个正交能力维度，互不影响，可自由组合
- 抽象类负责共性流程（如事务开启/回滚、重试上下文初始化），接口 default 方法只做轻量适配（如
retry()的简单封装） - 团队代码审查时，重点看：是否把本该是能力（can-do）的逻辑塞进了抽象类？是否用抽象类替代了本该由接口承担的跨域契约？
版本演进与兼容性红线
接口和抽象类的修改直接影响下游稳定性，必须立下硬规则：
- 公开接口禁止删除或修改方法签名；新增抽象方法必须配套提供 default 实现，或走重大版本升级流程
- 抽象类新增 protected 方法或字段可接受；但新增 public/abstract 方法需同步更新所有子类，必须发变更通告并设迁移期
- 所有抽象类和接口必须带 JavaDoc，明确标注：谁该实现它、为什么需要它、哪些方法可覆盖、哪些不可动
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
