17370845950

抽象应“刚好够用”，从问题域出发提炼核心行为与约束，优先用接口表达能力契约，按变化点设计粒度，通过命名、注释和文档明确边界，以支撑开闭原则并降低协作成本。

抽象程度不是越深越好，也不是越浅越安全，关键在于“刚好够用”——既能隐藏不必要的细节，又不丢失关键行为和约束。

从问题域出发定义抽象

抽象不是凭空设计出来的，而是对现实问题或业务逻辑的提炼。比如做电商系统，“商品”不是直接抽象成 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.* 下的契约”）

基本上就这些。抽象不是炫技，是给变化留缝、给协作划界、给维护减负。写完一个抽象，不妨自问一句：三个月后新人看到它，能不能不翻源码就大概明白该怎么用、不该怎么用？如果答案是肯定的，那这个抽象，八成是到位的。