抽象类应只定义骨架和契约，不实现业务细节；如支付流程中仅声明validate()等步骤，具体实现交由子类完成，避免混入状态判断、数据访问等越界逻辑。
抽象类不该变成“全知全能”的上帝类，核心是守住它的本分：只定义骨架和契约，不落地业务细节。
明确抽象类的职责边界
它只回答“做什么”，不负责“怎么做”。比如支付流程中，抽象类可以声明 validate()、calculateFee()、invokeChannel() 这些步骤，但每个方法的具体实现必须由子类提供。一旦发现抽象类里有 if (order.getStatus().equals("PAID")) 或 redisTemplate.opsForValue().set(...)，就说明它已经越界了。
把业务逻辑外移，交给策略或服务类
- 状态判断、校验规则、通知动作等，全部抽成独立接口，如 OrderValidator、PaymentNotifier
- 数据访问统一交给 Repository 接口，抽象类只依赖接口，不碰具体实现
- 需要复用的工具逻辑（如时间格式化、ID生成），封装为 protected final 方法，且不能带业务语义——formatTimestamp() 可以，sendSmsToBuyer() 不行
用组合代替“伪继承”式填充
别为了省几行代码，就把订单创建、重试策略、日志审计全塞进抽象父类。正确做法是：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 把可复用的能力拆成小组件，例如 OrderCreator、RetryPolicy、AuditLogger
- 在具体子类中以 private final 字段持有这些组件，按需调用
- 这样线上排查时，哪个环节出问题就换哪个组件，不影响整体结构
警惕上帝类失控信号
出现以下情况，说明抽象类正在膨胀失控：
- 构造函数注入了 OrderRepository、SmsSender、RedisTemplate 等多个具体服务
- 类里混着 saveToDb()、notifyUser()、logAudit() 等跨层职责
- 子类几乎不重写方法，所有逻辑都在父类跑完
- 单元测试要 mock 五六个协作对象才能跑通一个方法
此时应果断拆分：把行为抽象成接口，让抽象类只依赖这些接口，具体实现由子类或外部注入。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
