不要在父类的构造方法(代码块)里面调用可以被子类重写的方法
我们从第一天学习Java开始,就对Java的类初始化顺序牢记于心。但是在实际开发过程中,似乎很难能接触这一部分的应用。在这之前,我也认为它只是面试中八股文而已,直到最近踩了一个坑,这才发现它是多么的重要。
1. 说说坑?
地球人都知道,在Java世界中,类初始化顺序是:
- 父类的 静态成员变量 或者 静态代码块 --> 子类的 静态成员变量 或者 静态代码块 -->
- 父类 成员变量 或者 普通代码块 --> 父类的 构造方法 --> 子类 成员变量 或者 普通代码块 --> 子类的 构造方法。
我们在理解上都没有问题,但是使用上很容易忽略这个顺序。我举一个例子:假设有两个类,分别是Animal
和Dog
类,其中Dog
继承于Animal
(是不是感觉回到了学习Java的第一天?)。它们的代码如下:
public class Animal {
public Animal() {
eat();
}
protected void eat() {
}
}
// ----------------------------
public class Dog extends Animal {
private String foodName = "肉";
public Dog() {
}
@Override
protected void eat() {
System.out.println("我吃" + foodName);
}
}
代码实现很简单,总的来说就是:父类有一个非final
的方法在其构造方法里面回调,子类重写了这个方法,同时在这方法里面访问了一个自己的一个成员变量。
那么这里会什么问题呢?大家可以运行一下上面的代码,发现输出的结果是:我吃null
,也就是说foodName
还没有初始化。在这里,很容易理解为什么foodName
没有初始化,因为在类初始化顺序中,子类的成员变量在父类的构造方法之后才初始化。这个Demo足够的简单,所以大家觉得没有问题,在正式的开发环境中,情况一般都是非常复杂的,代码成千上万,我们在一个方法里面访问本类的成员变量,一般不会关心这个方法是什么时候回调的,从而导致在开发过程中遇到不可预知的结果。
不过幸运的是,这种问题是必现的,一般在开发中就能遇到并且解决,并不会带到线上去,但是我还是想说:父类的构造方法(代码块)里面不要调用可以被子类重写的方法。
除此以外,这种调用方式还会遇到一个隐式的问题:
public class Dog extends Animal {
private String foodName1;
private String foodName2 = null;
public Dog() {
}
@Override
protected void eat() {
foodName1 = "肉";
foodName2 = "骨头";
}
public void print() {
System.out.println("foodName1 = " + foodName1 + " foodName2 = " + foodName2);
}
}
我改写了Dog
类的代码,在其内部定义了两个成员变量,分别是:foodName1
和foodName2
,它们都在eat
方法里面赋值,需要注意的是,foodName2
在定义设置默认值为null
,而foodName1
没有设置默认值。那么我们创建Dog
的对象,然后调用它的print
方法,结果如何呢?结果是:foodName1 = 肉 foodName2 = null
。也就是说,设置默认值的成员变量即使在方法里面重新赋值,在真正使用的时候却还是默认值。这是为啥呢?其实要想真正了解其内部原理,就要扒Dog类的字节码了,但是我懒得扒,猜测其原因是:如果在定义成员变量没有设置默认值时,当其初始化时发现已经被初始化,就不再进行初始化。 换言之,如果设置了默认值,即使之前已经被赋值,也会被默认值覆盖。
相比于第一个坑,第二个坑显得更加隐式和不容易理解。总之还是那么一句话:父类的构造方法(代码块)里面不要调用可以被子类重写的方法。最重要的是,在这个过程中,编译器并没有做出任何提示,这也是这类问题容易出现的原因之一吧。
2. 聊聊Kotlin?
也许大家在Java中习惯了上面的使用方式,同时编译器也没有报错,说明官方也默认这种操作(我乱说的)。但是,我们以相同的方式应用在Kotlin中,编译器报了一个警告:
open class Test {
private val string = getString()
protected open fun getString(): String {
return ""
}
}
总体上来说,比Java友好的多,至少有了一个警告提示。
从这里,我们可以得出来两个结论:
- 不要随意忽略编译器给出的警告。
- 快去使用Kotlin吧!!!
补充:关于Kotlin中这个问题的视频讲解:[Kotlin] 为什么父类构造器不建议调用 open 的函数?(其实跟Java本质上是同样的问题)