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