Kotlin 代理是面试中经常被问到的问题,比如介绍一下代理的实现原理以及在使用中的一些注意事项等,本文将带你梳理这些问题,让你从更高维度上认识“代理”
Kotlin 有很多让人津津乐道的语法,“代理”就是经常被提及的一个。Kotlin 在语言级别通过 by 关键字支持了代理模式的实现。代理模式是最常用的设计模式之一,它是使用“组合”替代“继承”的最佳实践。下面取自 Wiki 中关于代理模式的例子:
class Rectangle(val width: Int, val height: Int) {
fun area() = width * height
}
class Window(val bounds: Rectangle) {
// Delegation
fun area() = bounds.area()
}
这是一个代理模式的典型场景:Window
将 area()
的具体实现委托给了 Retangle
类型对象 bounds
,Rectangle
与 Window
是代理与接收的关系。如果我们使用 Kotlin 的 by
关键字实现同样逻辑,代码变成下面这样:
interface ClosedShape {
fun area(): Int
}
class Rectangle(val width: Int, val height: Int) : ClosedShape {
override fun area() = width * height
}
class Window(private val bounds: ClosedShape) : ClosedShape by bounds
Kotlin 的 by
关键字只能基于接口进行代理,所以我们需要抽象出 Window
和 Rectangle
的共同接口 ClosedShape
,通过 by
关键字, Window
将 area()
委托给 bounds
来实现, Window
内部中省掉了直接调用 bounds
的代码。这个例子比较简单,优势体现的不明显,试想随着接口方法的增多,by 可以帮我们减少大量的模板代码。
虽然 by
关键字为我们带来了方便,但是它的一些机制也受到不少开发者诟病,甚至连 Kotlin 首席设计师 Andrey Breslav 都曾公开表示不喜欢这个功能。Kotlin 接口代理被诟病的问题主要有两个:
- 代理中无法访问 this
- 代理无法运行时替换
缺陷1:代理中无法访问 “this”
代理与继承的一个重要区别在于,继承关系中父类可以通过 this
访问运行时的真正实例;而代理关系中代理无法通过 this
直接访问接收方对象(例子中的 Window
),但有时我们确实需要获取接收方的状态参与计算,在 Java 中的常见做法是接收方在创建代理时注入自身实例。而 Kotlin 的 by
关键字需要在接收方实例化之前创建好代理,因此无法为代理注入 this
对象。
上面的例子中,假设 width
和 height
是 Window
维护的状态而非 Rectangle
,我们在 Rectangle
的 area()
中依赖它们来进行计算,此时该如何解决呢?一个可行的做法是在 Window
的 init
中注入向 Rectangle
注入所需的状态。这里需要注意两点,
- 第一,直接注入 width 和 height 是不行的,假设 Window 的 size 会变化,所以 Rectangle 需要在计算 area 时始终获取最新的数值,
- 第二,注入 Window 实例作为 “this”,通过 this 获取最新的 widht 和 height?这也是不妥的,Rectangle 依赖 Window 类型,会降低 Rectangle 的可复用性。
兼顾上述两点后,更合理的做法是为 Rectangle
定义一个可以获取 width/height
的函数类型,然后由 Wiindow
注入这个回调,代码如下:
interface ClosedShape {
fun area(): Int
}
class Rectangle : ClosedShape {
lateinit var size: () -> Pair<Int, Int>
override fun area() = size().let { it.first * it.second }
}
class Window(private val bounds: Rectangle) : ClosedShape by bounds {
private var width: Int = TODO()
private var height: Int = TODO()
init {
bounds.size = { width to height }
}
}
也许有人会提议为 area()
增加参数,动态传入 width
和 height
,但是这增加了 Window
的调用方的负担,违背面向对象中封装性的设计原则。
缺陷2:无法运行时替换代理
不少人希望代理模式中的代理能够根据需要动态替换,实现类似策略模式的效果。但这在目前 Kotlin 代理中是无法实现的。不少 Kotlin 的初学者曾经误认为通过 var
替换代理实例,比如下面代码中,我们将 Window
的参数 bounds
的声明从 val
改为 var
class Window(private var bounds: ClosedShape) : ClosedShape by bounds
但是经编译后的代码实际是下面这样,代理存储在 bounds
之外的另一个 final
成员 ``$$delegate_0` 中。
public final class Window implements ClosedShape {
private ClosedShape bounds;
// $FF: synthetic field
private final ClosedShape $$delegate_0;
public Window(@NotNull ClosedShape bounds) {
Intrinsics.checkNotNullParameter(bounds, "bounds");
super();
this.$$delegate_0 = bounds;
this.bounds = bounds;
}
public int area() {
return this.$$delegate_0.area();
}
}
即使我们在运行时为 bounds
赋值新的对象,代理中的实例也不会发生变化。 假设有这样的场景, Window
的形状在运行时会发生变化,相应地我们需要计算 area
的代理由 Rectangle
变为 Oval
,此时该如何解决呢? 一个不难想到的思路是:增加代理的“代理”,实现代理实例的可替换:
class Proxy(var target: ClosedShape) : ClosedShape {
override fun area() = target.area()
}
class Rectangle : ClosedShape {
lateinit var size: () -> Pair<Int, Int>
override fun area() = size().let { it.first * it.second }
}
class Oval : ClosedShape {
lateinit var size: () -> Pair<Int, Int>
override fun area() = size().let { Pi * it.first / 2 * it.second / 2 }
}
class Window(private val bounds: Proxy) : ClosedShape by bounds {
private var width: Int = TODO()
private var height: Int = TODO()
private val rectangle by lazy {
Rectangle().apply { size = { width to height } }
}
private val oval by lazy {
Oval().apply { size = { width to height } }
}
fun changeShape(mode: Shape) {
when (mode) {
Rectangle -> bounds.target = rectangle
Oval -> bounds.target = oval
}
}
}
上面代码中,我们定义了一个 Proxy
作为 Window
的代理,而真正被调用到的对象是 Proxy
的 target
,它可以在运行时根据需要做出变化。
但这也带来一个问题,如果接口中的方法很多,Proxy
中会出现大量的 target 的转发代码,增加我们的工作量。此时我们可以使用动态代理对其优化:
class Proxy(var target: ClosedShape?) {
fun create() : ClosedShape {
return newProxyInstance(
ClosedShape::class.java.getClassLoader(), arrayOf<Class<*>>(ClosedShape::class.java), object : InvocationHandler {
override fun invoke(proxy: Any?, method: Method, args: Array<out Any>?) = method.invoke(target, args)
}
) as ClosedShape
}
}
class Window(private val bounds: Proxy) : ClosedShape by bounds.create() {
//...省略
}
上面代码中,Proxy
的 create()
返回一个动态代理对象,帮节省了原本需要手动实现的转发代码。
对比其他解决方案
通过上面分析我们知道,使用 by
关键字创建的代理需要在接收方(例子中的 Window
)实例化之前确定,并且在编译后存储在一个不可见的 final
成员上,这使得接收方缺少对代理的直接控制的能力,比如无法在 Window
内创建代理,也无法在运行时替换代理。而对比 Kotlin 之外的其他同类解决方案中,你会发现接收方的控制力明显要强得多:
- Lombook (Kotlin 出现前常用的语法糖工具)提供了 @Delegate 注解,它可以帮助我们将接收方的成员声明为代理,无需再通过构造函数传入,接收方可以在自行创建代理的同时方便地做一些注入工作;
- Guava(Google 提供的 JDK 增强库)也提供了实现代理模式的 ForwardingObject,它允许我们在接收方内部通过重写
protected abstract Object delegate();
返回最新的代理对象,实现代理的可替换。
因此,我们可以简单下一个结论:Kotlin 代理之所以被人诟病,其根本原因在于相对于其他同类方案,接收方缺少对代理的直接控制的能力。目前有不少开发者提了相关 Issue,也许可以期待 Kotlin 在未来的版本中出现更合理的解决方案。在此之前,我们只能通过本文介绍一些 Workaround 进行应对。需要注意本文讲的代理仅仅指接口代理,相比之下,属性代理的设计合理得多,不存在上述这些问题。