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 进行应对。需要注意本文讲的代理仅仅指接口代理，相比之下，属性代理的设计合理得多，不存在上述这些问题。
