接口定义行为契约，抽象类提供骨架实现；接口强调“能做什么”，用于不相关类型的能力共享；抽象类强调“怎么统一做”，适用于强关联类的共性封装。
接口与抽象类在 Java API 设计中承担不同角色：接口定义契约，抽象类提供可复用的骨架实现。设计规范 API 时，关键不是“用哪个”，而是“为什么用”和“怎么用才不破坏扩展性与职责边界”。
接口用于定义稳定、可组合的行为契约
当多个不相关类型需要共享同一组操作能力时，优先用接口。它强调“能做什么”，而非“是谁”。比如日志系统中，Logger 接口只声明 info()、error() 等方法，而具体实现可以是 Log4jLogger、SLF4JAdapter 或 MockLogger，互不影响。
- 接口方法默认 public，不写修饰符；避免在接口中定义非静态、非 final 的字段
- 新增方法要谨慎——Java 8+ 支持 default 方法，但仅限向后兼容的增强（如加
logWarn(String)），不可用于改变原有语义 - 一个接口只聚焦一个能力维度，例如
Serializable、Comparable、Closeable，避免出现“全能接口”
抽象类用于封装共性逻辑与强制子类约定
当你有一组强关联的类，它们共享状态、算法骨架或初始化流程时，抽象类更合适。它回答的是“怎么统一做这件事”，并保留子类定制点。比如 HTTP 客户端基类 HttpClientBase 可封装连接池管理、重试策略、超时配置，同时留出 buildRequest() 和 parseResponse() 两个 abstract 方法由子类实现。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 抽象类可含构造函数、成员变量、protected 方法，适合构建可测试的模板结构
- 不要为了“看起来像继承”而滥用抽象类；如果子类之间没有天然的 is-a 关系，就该用组合+接口
- 抽象类本身应尽量无状态，或状态仅服务于其定义的算法流程，避免变成“半成品实现类”
组合优于继承，接口优先于抽象类
现代 Java API 设计倾向先定义接口，再提供默认实现类（如 Collection 接口 + AbstractCollection 抽象类 + ArrayList 具体类）。这种分层让使用者有选择权：想轻量集成？直接实现接口；想快速起步？继承抽象类；想完全控制？自己写实现。
立即学习“Java免费学习笔记（深入）”；
- 对外暴露的 API 类型首选接口，降低使用者耦合度（如 Spring 的
BeanFactory、MyBatis 的SqlSession） - 抽象类更适合框架内部使用，或作为 SDK 提供的“参考实现”，不建议作为公共 API 的主要入口
- 接口可多实现，抽象类只能单继承——这点决定了接口更适合能力叠加（如一个类同时
implements Runnable, Comparable, AutoCloseable）
配合 SOLID 原则落地设计
接口和抽象类不是语法技巧，而是支撑设计原则的工具。比如开闭原则（OCP）靠接口实现：新增一种支付方式，只需新增 AlipayPayment 实现 Payment 接口，无需动订单服务代码；里氏替换原则（LSP）靠抽象类约束：所有 NotificationSender 子类必须保证 send() 调用后不抛出未声明异常，否则上层逻辑会崩。
- 单一职责：接口只声明一类行为，抽象类只封装一类流程
- 依赖倒置：高层模块（如 Service）依赖
Payment接口，而非WechatPayment具体类 - 接口隔离：拆分大接口为小接口（如把
UserService拆成UserQueryService和UserModifyService），避免实现类被迫实现无用方法
