Java继承常见问题及避免方法

Java继承本身并非缺陷，但实践中常被误用为代码复用的捷径，而非严格表达“is-a”语义关系，由此引发封装破坏、状态不一致、构造器中空指针等棘手问题；文章直击痛点，倡导以组合优先替代盲目继承、严控protected暴露、禁用构造器中可重写方法调用，并强调真正难点不在技术约束，而在扭转团队将继承等同于便利的思维惯性——读懂这些，才能写出可维护、可测试、真正面向演化的Java代码。

为什么 extends 一用就出问题？

Java 中继承本身没问题，但多数问题源于把 extends 当成“代码复用首选”，而不是“明确的 is-a 关系建模工具”。比如让 Employee 继承 Person 没问题，但让 Stack 继承 Vector（JDK 早期错误）就破坏了封装——子类被迫暴露父类所有 public 方法，哪怕语义上根本不该调用 removeElementAt()。

常见症状包括：NullPointerException 在父类构造器中调用被子类重写的 hook 方法、子类意外覆盖父类关键逻辑、final 修饰缺失导致不可控的重写。

用组合替代继承的实操要点

不是禁止继承，而是优先考虑组合。比如要实现一个带缓存的数据库访问器，别写 class CachedDao extends JdbcDao，而应：

• 定义接口 Dao，让 JdbcDao 和 CachedDao 都实现它
• CachedDao 内部持有一个 Dao 实例（如 private final Dao delegate;），只在需要时委托调用
• 缓存逻辑完全隔离，不污染数据访问契约

这样既避免了继承链断裂风险，又便于单元测试（可注入 mock Dao）。

protected 字段和方法是最大隐患源

很多继承问题实际来自滥用 protected。一旦父类暴露 protected List items;，子类就能随意修改，导致父类内部状态不一致。

更安全的做法：

• 把字段全设为 private，提供受控的 protected 方法（如 protected void addItem(String item)）而非裸字段
• 若必须开放状态访问，返回不可变视图：return Collections.unmodifiableList(items);
• 考虑用 final 修饰父类方法，或整个类（如 public final class StringUtils），从源头封住继承可能

构造器里调用可重写方法为何危险？

这是最隐蔽也最常踩的坑。父类构造器执行时，子类字段尚未初始化，此时调用被子类重写的实例方法，很可能读到 null 或默认值。

示例：

class Parent {
    Parent() {
        init(); // 实际调用的是 Child.init()
    }
    void init() { }
}

class Child extends Parent {
    private String config = loadConfig(); // 此时尚未执行
    void init() {
        System.out.println(config.length()); // NullPointerException!
    }
}

解决方式只有两个：把 init() 设为 final，或改用工厂方法 + 显式初始化步骤（如 new Child().setup()）。

真正难处理的不是语法限制，而是团队对“继承即强耦合”的认知惯性——哪怕加了 @Deprecated 的 extends，只要编译通过，就有人会用。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~