应严格遵循“is-a”语义建继承，如Manager is-a Employee；避免Order extends Product等错误；继承深度不超过两层；父类仅含稳定共性；优先组合替代继承；谨慎设计可继承性。

明确“is-a”关系再建继承

继承不是为了复用而复用，而是为表达真实的类型归属。比如 Manager extends Employee 合理，因为经理确实是一种员工；但 Order extends Product 就错误——订单不是商品的一种，而是“包含”商品，该用组合。语义不成立的继承，一写就埋下高耦合隐患。

限制继承深度，两层封顶

超过两层的继承链（如 A → B → C → D）会让修改成本陡增，且每层职责容易模糊。建议：

• 顶层定义领域核心概念（如 PaymentMethod）
• 中间层做技术归类（如 OnlinePayment）
• 叶子层才是具体实现（如 WechatPay、Alipay）
• 避免使用 BaseService、CommonEntity 这类无业务含义的父类名

父类只放稳定共性，拒绝“强行抽象”

多个子类都有的字段或方法，才上提到父类。判断标准是：这个逻辑未来是否大概率被所有子类一致使用？

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

• ✅ 可以上提：创建时间、ID、状态码、统一日志打点
• ❌ 不该上提：“头像URL”（仅用户有）、“收货地址”（仅订单有）、“电池续航”（仅手机有）
• 宁可子类各自写两行代码，也不在父类塞 null 字段或类型转换逻辑

优先用组合替代继承

当目标只是调用某功能，而非扩展类型体系时，组合更安全可控：

立即学习“Java免费学习笔记（深入）”；

• 用 private final Logger logger 替代继承一个 Loggable 父类
• 用 private final CacheService cache 替代让业务类继承 CacheSupport
• 依赖声明为接口（如 DataSource），运行时可自由替换实现
• 构造器注入依赖，避免空指针和后期篡改

谨慎设计父类的可继承性

不是所有类都适合被继承。检查父类是否真正“欢迎”子类：

• 看 JavaDoc 是否注明 “This class is designed for inheritance”
• 关键方法是否被 final 修饰，防止误重写破坏流程
• 是否有大量 protected 字段却无文档说明使用约束
• 像 String、LocalDateTime 这类不可继承，不是限制你，是它们的状态契约太脆弱