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

Java继承本身并非缺陷，但多数问题源于将其误用为代码复用的捷径，而非严格服务于“is-a”语义建模——从Stack继承Vector破坏封装，到构造器中调用可重写方法引发NullPointerException，再到protected滥用导致状态失控，根源都在于忽视继承带来的强耦合与脆弱性；文章直击要害，倡导以组合优先替代继承、严控protected暴露、禁用构造器中的多态调用，并强调真正难点不在技术约束，而在扭转团队将“能编译通过”等同于“设计合理”的认知惯性。

为什么 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，只要编译通过，就有人会用。

今天关于《Java继承常见问题及规避方法》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！