继承应严格遵循“is-a”关系，如animal→dog；避免user→order等错误用法；优先用抽象类封装共性，控制层级不超过两层；非“is-a”场景推荐组合而非继承。
继承确实能简化类结构，但关键在于“怎么用”——不是所有相似都该用继承，而是把真正符合“is-a”关系的共性抽出来，让代码变清晰、易维护，而不是堆出更深的层级。
明确“is-a”关系再建继承链
只有当子类确实是父类的一种时，才适合继承。比如“狗是动物”“学生是人”，这种天然的分类关系才能支撑起清晰的结构。如果强行让“订单”继承“用户”，逻辑就乱了，后期改起来反而更费劲。
- ✅ 推荐：Animal → Dog / Cat / Bird
- ❌ 避免：User → Order / Payment（这是“has-a”或“uses-a”，更适合用组合）
用抽象类封装共性，留出扩展空间
把多个子类都有的字段（如name、id）、通用方法（如save()、toString()）放到抽象父类里，既避免重复，又防止父类被误实例化。子类只需专注自己独有的行为。
- 抽象类可含具体方法 + 抽象方法，比普通类更适合作为基底
- 比如定义一个Shape抽象类，包含getArea()抽象方法和setColor()具体方法，Circle和Rectangle各自实现面积逻辑，复用颜色设置
控制继承深度，优先扁平化设计
超过三层的继承链（如A→B→C→D）会显著增加理解成本和修改风险。一个bug可能要翻四层代码才能定位；父类一改，下游全抖。
- 建议继承层级不超过2层：基类 → 业务子类（必要时加一层中间抽象类）
- 功能差异大的分支，考虑拆成独立类+接口统一行为，而不是硬塞进同一继承树
搭配组合，替代不自然的继承
当两个类之间不是“是什么”，而是“有什么”或“用什么”时，组合更轻量、更灵活。比如“汽车有发动机”“用户有头像”，直接在类里声明private Engine engine;比让它继承Engine合理得多。
- 组合让类职责单一，修改某个部件不影响整体结构
- 运行时可替换组件（如换不同类型的Logger），继承则在编译期就固定了关系
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
