Java继承核心作用有哪些？代码复用详解

Java继承的核心作用是实现编译期的成员获取与运行时多态，使子类能直接访问父类非私有成员并支持向上转型、方法重写和动态分派，但其本质并非万能代码复用手段——过度依赖易引发紧耦合、维护困难和语义失真；真正稳健的设计应优先选择组合与接口实现，仅在满足稳定、不可变的“is-a”关系（如ArrayList是一种List）时才谨慎使用继承，否则极易将“has-a”或“uses-a”误写为继承，埋下系统性重构隐患。

继承让子类直接获得父类的非私有成员

Java 中 extends 的本质，是让子类在编译期就“复制”了父类的 public 和 protected 字段、方法（不包括构造器），以及默认访问权限下同包可见的成员。这不是运行时动态挂载，而是编译器生成的符号引用绑定。

这意味着：

class Animal {
    protected String name;
    public void eat() { System.out.println(name + " is eating"); }
}
class Dog extends Animal {
    public void bark() { System.out.println(name + " is barking"); }
}

中，Dog 实例能直接访问 name 并调用 eat()，因为 JVM 在加载 Dog 类时已确认其继承链并验证了访问权限。

• 私有字段（private）不会被继承，子类不可见，也不能通过 super.xxx 访问——除非父类提供了 public/protected 的 getter/setter
• 构造器不会被继承，但子类构造器必须显式或隐式调用 super()，否则编译失败
• 静态成员属于类本身，子类“可访问”但不是“继承”；修改 static 字段会影响所有类共享的值，和继承无关

继承是实现运行时多态的前提

没有继承（或接口实现），instanceof 判断、向上转型、方法重写（@Override）都无从谈起。JVM 依靠类的继承关系构建虚方法表（vtable），才能在运行时根据实际对象类型分派方法调用。

例如：

List animals = new ArrayList<>();
animals.add(new Dog());
animals.add(new Cat());
for (Animal a : animals) {
    a.makeSound(); // 运行时才决定调用 Dog.makeSound() 还是 Cat.makeSound()
}

若 Dog 和 Cat 没继承自 Animal，这段代码连编译都过不了——泛型约束、循环变量类型、方法调用合法性全依赖继承建立的类型兼容性。

• 重写（override）必须满足：方法名、参数列表、返回类型（协变允许子类型）一致，且访问权限不能更严格
• final 方法不能被重写，final 类不能被继承，这是 JVM 强制的契约边界
• 字段不支持多态：即使子类定义了同名字段，访问时仍按引用类型决定——Animal a = new Dog(); a.name 取的是 Animal 的 name，不是 Dog 的

继承不是代码复用的万能解，容易导致紧耦合

很多人误以为“复用代码 = 用 extends”，结果写出深度继承树，比如 Vehicle → Car → ElectricCar → TeslaModel3。一旦中间某层语义变化（如 Car 新增强制油箱字段），所有下游子类都要改。

真正安全的复用优先级应是：组合 > 接口实现 > 继承。比如把“能导航”抽成 Navigator 接口，让 Car 和 Smartphone 都实现它，比让后者继承前者合理得多。

• 继承暴露父类实现细节，子类被迫依赖其内部逻辑；组合则通过接口隔离，父类换实现不影响子类
• Java 不支持多继承，但一个类可实现多个接口，组合+接口能模拟更灵活的关系
• 单元测试时，继承链越长，mock 越困难；组合对象可单独测试，再注入到宿主类中

什么时候该用继承？看是否满足“is-a”且语义稳定

判断标准不是“有没有共用代码”，而是“子类是不是父类的一种”。比如 ArrayList 是一种 List，IOException 是一种 Exception——这些关系在 JDK 设计时就被固化，极少变动。

反例：Stack 继承 Vector（旧版 JDK）曾被诟病，因为栈不是向量，只是“用向量实现栈操作”，后来 Java 提供 Deque 接口 + ArrayDeque 实现，更准确反映“栈是一种双端队列”的语义。

• 如果父类是 final、private 构造、或文档明确写“designed for extension”，才放心继承
• 业务代码中，优先用 abstract class 定义模板逻辑（如统一日志、事务模板），再由具体子类填充 abstract 方法
• 避免为复用工具方法而继承——那些本该是 static 工具类或 default 接口方法

继承机制本身很清晰，难的是在设计初期就识别出真正的“is-a”关系。多数维护事故，都源于把“has-a”或“uses-a”强行写成“is-a”。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Java继承核心作用有哪些？代码复用详解》文章吧，也可关注golang学习网公众号了解相关技术文章。