抽象应“刚好够用”，从问题域出发提炼核心行为与约束，优先用接口表达能力契约，按变化点设计粒度，通过命名、注释和文档明确边界，以支撑开闭原则并降低协作成本。
抽象程度不是越深越好，也不是越浅越安全，关键在于“刚好够用”——既能隐藏不必要的细节，又不丢失关键行为和约束。
从问题域出发定义抽象
抽象不是凭空设计出来的，而是对现实问题或业务逻辑的提炼。比如做电商系统，“商品”不是直接抽象成 Product 类就完事，要先问：哪些属性和行为在当前场景下必须被统一处理？库存变动、价格策略、上下架状态是否共用？如果促销模块只关心“是否可售”和“最终价格”，那“商品”的抽象就该聚焦在这两个能力上，而不是塞进SKU、类目树、审核流等全量字段。
- 画出核心业务流程，标出重复出现的概念（如“支付”“订单”“用户”）
- 对每个概念，列出它在当前上下文中“必须做什么”和“不能做什么”
- 把“必须做”的部分抽成接口或抽象类，把“不能做”变成访问控制或运行时校验
接口比抽象类更适合作为第一层抽象
Java 中接口天然表达“能力契约”，不带实现、无状态、支持多继承，更适合描述“是什么”而非“是谁”。比如日志记录，与其写一个 AbstractLogger，不如定义 Loggable 接口，让 Order、User、Payment 各自决定怎么记录自己的关键事件。这样既避免了父类强耦合，又便于后期用 AOP 或代理统一增强。
- 优先用
interface描述角色（Runnable,Comparable,Serializable） - 抽象类适合封装“怎么做”的共性逻辑（如模板方法、默认工具方法），但别让它承担“是什么”的职责
- 接口中尽量只放 public 方法，避免 default 方法膨胀成微型实现类
抽象粒度跟着变化点走
真正需要抽象的地方，是那些“可能变”或“已经变了多次”的地方。比如支付方式从微信扩展到支付宝、PayPal，这就是典型的变化点；而“创建时间”字段几乎不会变，就没必要为它单独抽象一个 Timestamped 接口（除非多个模块反复按时间过滤+排序+序列化，且格式不一致）。
- 用“开闭原则”倒推：新增一种实现时，是否只需加新类、不改老代码？如果不是，说明抽象漏了变化维度
- 警惕过早抽象：没出现第二个实现前，先用具体类+清晰命名（如
WechatPayService），等 PayPal 加进来再提取PayService接口 - 抽象层级一般不超过两层：接口 → 具体实现，或 接口 → 抽象基类 →
具体实现；三层以上往往意味着职责割裂或模型失真
具体实现；三层以上往往意味着职责割裂或模型失真用注释和命名守住抽象边界
再好的抽象，如果别人看不懂“这个接口到底管什么”，就会被误用或绕过。Java 没有类型级文档强制机制，所以得靠名字 + Javadoc + 示例代码来传达设计意图。
- 接口名用能回答“它能干什么”的动宾结构：
OrderValidator而非IOrderCheck - Javadoc 第一行写清楚“谁该实现它”“谁会调用它”“违反约定会导致什么后果”
- 在 module-info.java 或包注释里说明该包内抽象的适用范围（如：“本包接口仅用于交易核心链路，风控模块请使用
fraud.*下的契约”）
基本上就这些。抽象不是炫技，是给变化留缝、给协作划界、给维护减负。写完一个抽象，不妨自问一句：三个月后新人看到它，能不能不翻源码就大概明白该怎么用、不该怎么用？如果答案是肯定的，那这个抽象，八成是到位的。
