深入理解backing field

最近，一个同学突然问到一个问题：为什么扩展属性不能直接进行初始化？针对这个问题，官方文档有一段简短的解释，翻译成中文就是：实际上，扩展并不会真正地往类中插入成员变量。因此，我们没有一个有效的方式让一个扩展属性拥有backing field，这就是扩展属性不允许被初始化的原因。大多数同学看到上面这一段话肯定是一头雾水，但我们抓到了一个关键词backing field。解释这个问题，其实就是理解backing field的本质。

backing field是什么

这个词语不好翻译，很多译文将其翻译为幕后属性或幕后字段。的确，有那么一层意思，但总感觉不是很贴切。因此，这篇文章我们始终使用这个官方英文单词来表示。

在Kotlin语言中，如果在类中定义一个成员变量，Kotlin将自动生成默认setter/getter方法。而Kotlin提供了一种非常特殊的方式声明setter/getter方法：

这里我们直接使用了本次的主人公field字段，如果不使用会怎样呢？你应该很自然地想到这样处理：

实例化这个类，然后对当前实例的name属性进行赋值并取值。Oops…结果，你会发现，无论是取值还是赋值都出现递归调用。

这是为什么呢？是的，聪明的你肯定已经想到了。我们在setter方法中对name赋值的时候会调用自身，结果出现了递归调用，getter方法同理。

这个时候救世主backing field降临了。backing field的作用域仅仅存在于当前属性的setter/getter方法中，它就像当前属性的影子一样。因此，我认为翻译成影子属性也许更合适。

理解了backing field的意图之后，我们再来解释为什么扩展属性不能直接初始化。这个时候，使用正向思维直接推导就可以了。假设对扩展了一个属性，假设可以直接初始化，声明看起来应该是这样：

注意：Kotlin语言针对属性默认会生成setter/getter方法，其默认实现是这样的：

我们看到了熟悉的老朋友，由于扩展属性并不会真正地在类中插入字段，那这个field自然就无处安放了。有人说，可以放在全局吗？

当然不行！是什么？是当前属性的影子。而当前属性是与某个实例一一对应的。这就是为什么官方文档说，没有一个有效的办法使扩展属性拥有field字段。结果就尴尬了！声明扩展属性的时候我们就不得不自己实现setter/getter方法。

这里大家还可以做一个简单的实验，使用上述的定义方式，看看最终Kotlin帮忙生成的setter/getter代码是什么。这里我直接将实验结果展示给大家看：

简单总结

至此，整个问题的谜底已经揭晓了。由于Java语言中不存在backing field这样一个属性，难免会导致理解上的问题。这个时候可以使用逆推 + 猜想的方式寻找答案。文章最后我给出了Kotlin帮忙生成的代码片段，这是怎么做到的呢？其实很简单，先使用Kotlin编译器将Kotlin代码编译成Java字节码，再用JD-GUI反编译class文件就可以看到最终生成的Java代码了。

我是欧阳锋，我热爱Kotlin。如果你喜欢我的文章，请在文章下方留下你爱的小心心。如果你不喜欢我的文章，请先喜欢上我的文章。然后再留下爱的小心心！

下次文章再见，拜拜！

欢迎加入Kotlin交流群编程，我们是认真的！长按下方二维码，关注欧阳锋工作室，你想要的都在这里：

欧阳锋工作室