java类设计核心是职责分离：extends表“是什么”，implements表“能做什么”；优先组合、接口、final修饰与构造器安全，严守里氏替换原则。
Java中设计良好的类层次结构，核心不是堆砌继承，而是让extends和implements各自承担明确职责：继承表达“是什么”，接口表达“能做什么”。
用组合替代深层继承链
当发现子类只复用父类部分行为，或继承层级超过3层（如Animal → Mammal → Carnivore → Lion），大概率违反开闭原则且难以维护。
- 把可复用逻辑抽成独立类（如
LegMovement、RoarBehavior），通过字段持有而非继承 - 用
final修饰不打算被重写的类或方法，避免子类意外破坏契约 - 避免在父类构造器中调用
protected或public方法——子类可能尚未初始化完毕
接口优先于抽象类定义能力契约
抽象类适合共享状态与默认实现（如AbstractList封装size字段和基础遍历逻辑）；接口更适合定义角色能力（如Runnable、Comparable）。
- 接口方法默认
public abstract，Java 8+ 可加default方法提供非破坏性扩展 - 一个类可实现多个接口，但只能继承一个类——能力组合应靠接口实现
- 避免“胖接口”：像
java.io.Serializable这种标记接口没问题，但若接口包含10+方法，说明职责过重，应拆分为Readable、Writable等
里氏替换原则（LSP）的实操检验点
子类对象替换父类对象后，程序行为不变。这不是理论要求，而是运行时可验证的约束。
立即学习“Java免费学习笔记（深入）”；
- 子类不能缩小父类方法的访问权限（如父类
protected void save()，子类不能改为private） - 子类重写方法时，输入参数范围不能比父类更窄（如父类接受
Object，子类不能只接受String） - 子类抛出的异常类型不能比父类更宽（如父类声明
throws IOException，子类不能加throws Exception） - 最易忽略：子类重写
getXXX()方法时，返回值若为集合，必须保证不可变性或明确文档化可修改性——否则调用方按父类契约使用时会出错
抽象基类的构造器设计陷阱
抽象类不是模板，它的构造器执行时机常被误判：它在子类super()调用时执行，早于子类字段初始化。
- 不要在抽象类构造器中调用
abstract方法——实际执行的是子类重写版本，而子类字段还是默认值（null、0等） - 若需强制子类提供某些信息，用
final字段 + 构造器参数传递，而非依赖子类重写方法返回 - 考虑用静态工厂方法替代
new直接实例化抽象类子类，例如Shape.of("circle")内部返回Circle实例，隐藏具体类型
真正难的不是写出能编译的继承结构，而是每次添加extends或implements前，能清晰说出这个关系在业务语义上是否成立、在运行时是否安全、在后续修改中是否容易被破坏。
