聊聊 Kotlin 代理的“缺陷”与应对

4,049 阅读6分钟

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()
}

这是一个代理模式的典型场景:Windowarea() 的具体实现委托给了 Retangle 类型对象 boundsRectangleWindow代理接收的关系。如果我们使用 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 关键字只能基于接口进行代理,所以我们需要抽象出 WindowRectangle 的共同接口 ClosedShape,通过 by 关键字, Windowarea() 委托给 bounds 来实现, Window 内部中省掉了直接调用 bounds 的代码。这个例子比较简单,优势体现的不明显,试想随着接口方法的增多,by 可以帮我们减少大量的模板代码。

虽然 by 关键字为我们带来了方便,但是它的一些机制也受到不少开发者诟病,甚至连 Kotlin 首席设计师 Andrey Breslav 都曾公开表示不喜欢这个功能。Kotlin 接口代理被诟病的问题主要有两个:

  • 代理中无法访问 this
  • 代理无法运行时替换

缺陷1:代理中无法访问 "this"

代理与继承的一个重要区别在于,继承关系中父类可以通过 this 访问运行时的真正实例;而代理关系中代理无法通过 this 直接访问接收方对象(例子中的 Window),但有时我们确实需要获取接收方的状态参与计算,在 Java 中的常见做法是接收方在创建代理时注入自身实例。而 Kotlin 的 by 关键字需要在接收方实例化之前创建好代理,因此无法为代理注入 this 对象。

上面的例子中,假设 widthheightWindow 维护的状态而非 Rectangle,我们在 Rectanglearea() 中依赖它们来进行计算,此时该如何解决呢?一个可行的做法是在 Windowinit 中注入向 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() 增加参数,动态传入 widthheight,但是这增加了 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 的代理,而真正被调用到的对象是 Proxytarget,它可以在运行时根据需要做出变化。

但这也带来一个问题,如果接口中的方法很多,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() {
   
    //...省略
    
}

上面代码中,Proxycreate() 返回一个动态代理对象,帮节省了原本需要手动实现的转发代码。

对比其他解决方案

通过上面分析我们知道,使用 by 关键字创建的代理需要在接收方(例子中的 Window)实例化之前确定,并且在编译后存储在一个不可见的 final 成员上,这使得接收方缺少对代理的直接控制的能力,比如无法在 Window 内创建代理,也无法在运行时替换代理。而对比 Kotlin 之外的其他同类解决方案中,你会发现接收方的控制力明显要强得多:

  • Lombook (Kotlin 出现前常用的语法糖工具)提供了 @Delegate 注解,它可以帮助我们将接收方的成员声明为代理,无需再通过构造函数传入,接收方可以在自行创建代理的同时方便地做一些注入工作;
  • Guava(Google 提供的 JDK 增强库)也提供了实现代理模式的 ForwardingObject,它允许我们在接收方内部通过重写 protected abstract Object delegate(); 返回最新的代理对象,实现代理的可替换。

因此,我们可以简单下一个结论:Kotlin 代理之所以被人诟病,其根本原因在于相对于其他同类方案,接收方缺少对代理的直接控制的能力。目前有不少开发者提了相关 Issue,也许可以期待 Kotlin 在未来的版本中出现更合理的解决方案。在此之前,我们只能通过本文介绍一些 Workaround 进行应对。需要注意本文讲的代理仅仅指接口代理,相比之下,属性代理的设计合理得多,不存在上述这些问题。