TypeScript父类调用子类方法时的子类属性作用域问题

这个问题我太熟了！本质是Java对象初始化顺序的陷阱，加上父类构造器调用可重写方法的不良实践导致的，咱们一步步拆解：

先复现你的代码场景 #

首先把你描述的场景写成可运行的Java代码，方便理解问题：

父类Father #

abstract class Father {
    public Father() {
        // 构造器中调用抽象方法
        load();
    }

    public abstract void load();
}

子类Child #

class Child extends Father {
    // 子类独有属性，显式赋值初始值
    private String _childExtraData = "初始值";

    public Child() {
        super(); // 默认调用父类构造器
    }

    @Override
    public void load() {
        // 尝试修改子类属性
        _childExtraData = "修改后的值";
        System.out.println("load方法内的_childExtraData：" + _childExtraData);
    }

    public void printFinalData() {
        System.out.println("最终的_childExtraData：" + _childExtraData);
    }
}

测试代码 #

public class TestDemo {
    public static void main(String[] args) {
        Child child = new Child();
        child.printFinalData();
    }
}

运行结果 #

你会看到控制台输出：

load方法内的_childExtraData：修改后的值
最终的_childExtraData：初始值

完全符合你描述的现象：代码没报错，但属性没被修改。

为什么会出现这个问题？ #

核心原因是Java对象的初始化顺序，当你创建Child实例时，执行流程是这样的：

1. 为Child对象分配内存，所有实例变量先做默认初始化（比如_childExtraData此时是null）
2. 调用子类构造器的super()，进入父类Father的构造器
3. 父类构造器调用load()，由于load()是抽象方法，实际执行的是子类Child的load()实现——此时_childExtraData被改成了"修改后的值"
4. 父类构造器执行完成，回到子类构造器，此时执行子类实例变量的显式赋值：_childExtraData = "初始值"，这一步直接覆盖了load()里修改的值
5. 子类构造器剩余代码执行（这里没有额外代码），对象创建完成

简单说：你在load()里改的值，被子类属性的显式初始化给覆盖了！

而更深层的问题是：永远不要在父类构造器中调用可重写的方法（包括抽象方法），这是Java开发中的经典反模式——因为此时子类还未完成初始化，调用子类方法可能导致不可预期的行为。

解决方案 #

方案1：调整子类属性的初始化时机 #

把子类属性的显式赋值逻辑整合到load()方法中，或者去掉显式赋值，让load()直接设置最终值：

class Child extends Father {
    private String _childExtraData; // 去掉显式初始化

    public Child() {
        super();
    }

    @Override
    public void load() {
        // 先设置初始值，再修改成目标值（根据需求调整）
        _childExtraData = "初始值";
        _childExtraData = "修改后的值";
        System.out.println("load方法内的_childExtraData：" + _childExtraData);
    }

    public void printFinalData() {
        System.out.println("最终的_childExtraData：" + _childExtraData);
    }
}

方案2：重构父类，避免构造器调用可重写方法（推荐） #

这是更稳妥的最佳实践：把初始化逻辑从构造器中剥离，提供一个单独的初始化方法，让子类实例创建后主动调用：

修改后的父类Father

abstract class Father {
    public Father() {
        // 构造器中不再调用抽象方法
    }

    public abstract void load();

    // 对外提供初始化入口
    public void init() {
        load();
    }
}

修改后的测试代码

public class TestDemo {
    public static void main(String[] args) {
        Child child = new Child();
        // 实例创建完成后，主动调用初始化方法
        child.init();
        child.printFinalData();
    }
}

这样就能保证：子类所有属性都完成初始化后，再执行load()方法修改属性，完全避免了初始化顺序的问题。

总结 #

这个问题的本质是Java初始化顺序的特性，加上父类构造器调用可重写方法的不良实践导致的。记住一个核心原则：父类构造器中永远不要调用子类可以重写的方法，否则很容易踩这类初始化陷阱。

内容的提问来源于stack exchange，提问作者DAEMonRaco