Kotlin 中的委托模式 | Baeldung中文网

1. 概述

在很多场景下，使用委托（delegation）比继承更优。Kotlin 在语言层面原生支持委托模式，这让代码更加简洁、灵活且易于维护。

本文将深入讲解 Kotlin 对委托模式的原生支持，并通过实际示例展示其用法和优势。对于有经验的开发者来说，掌握这一特性可以有效避免“过度继承”带来的耦合问题，是一种典型的“组合优于继承”实践。

✅ 推荐使用场景：扩展第三方类功能、实现多接口聚合、线程安全包装等
❌ 避免踩坑：不要误以为委托对象能感知装饰器的状态变化

2. 实现方式

假设我们有一个第三方库提供的接口和实现如下：

interface Producer {

    fun produce(): String
}

class ProducerImpl : Producer {

    override fun produce() = "ProducerImpl"
}

现在我们需要在不修改原始实现的前提下增强其行为 —— 比如追加一些上下文信息。这时就可以使用 Kotlin 的 by 关键字进行委托：

class EnhancedProducer(private val delegate: Producer) : Producer by delegate {

    override fun produce() = "${delegate.produce()} and EnhancedProducer"
}

📌 核心要点：

by delegate 表示该类自动实现 Producer 接口，并将未重写的方法默认转发给 delegate
我们仅需覆盖需要定制的方法（如 produce()），其余方法仍由 ProducerImpl 处理
构造参数中的 delegate 是依赖注入的典型体现，利于测试和解耦

验证效果：

val producer = EnhancedProducer(ProducerImpl())
assertThat(producer.produce()).isEqualTo("ProducerImpl and EnhancedProducer")

输出结果符合预期，说明委托与方法重写协同工作正常。

3. 常见使用场景

3.1 聚合多个接口实现

当一个类需要同时具备多种服务能力时，传统 Java 可能会采用多重继承模拟（通过抽象类组合），但 Kotlin 提供了更优雅的方式 —— 多接口委托：

class CompositeService : UserService by UserServiceImpl(), MessageService by MessageServiceImpl()

这种方式的优势在于：

✅ 零样板代码：无需手动转发每个方法
✅ 易于替换实现：可通过构造函数传入不同实例
✅ 支持混合代理：可部分方法重写，部分委托

💡 提示：这种模式非常适合构建聚合服务（Aggregate Service）或适配器组件。

3.2 增强现有实现（装饰器模式）

另一个典型用途是为已有逻辑添加横切关注点，比如日志、监控、同步控制等。尤其适用于无法修改源码的情况（如第三方库）。

例如，让一个非线程安全的 Producer 变成线程安全版本：

class SynchronizedProducer(private val delegate: Producer) : Producer by delegate {

    private val lock = ReentrantLock()

    override fun produce(): String {
        lock.withLock { 
            return delegate.produce()
        }
    }
}

⚠️ 注意事项：

尽管我们只重写了 produce()，但所有其他方法仍通过 by delegate 自动代理
锁的作用范围清晰，不会影响接口契约
若后续 Producer 新增方法，无需修改此装饰器即可自动支持（只要不需同步）

这是典型的运行时装饰，相比继承更轻量、更安全。

4. 委托 ≠ 继承

虽然语法上看起来像是某种形式的继承，但实际上 Kotlin 的接口委托机制与继承有本质区别。

最关键的一点是：被委托的对象（delegate）完全不知道装饰器的存在。

来看一个容易踩坑的例子：

interface Service {

    val seed: Int

    fun serve(action: (Int) -> Unit)
}

class ServiceImpl : Service {

    override val seed = 1

    override fun serve(action: (Int) -> Unit) {
        action(seed)
    }
}

class ServiceDecorator : Service by ServiceImpl() {
    override val seed = 2
}

你以为 serve 会传入 2？错！

执行测试：

val service = ServiceDecorator()
service.serve {
    assertThat(it).isEqualTo(1)
}

✅ 实际输出是 1，因为：

ServiceImpl.serve() 内部引用的是它自己定义的 seed（值为 1）
即便 ServiceDecorator 重写了 seed，ServiceImpl 并不知道也不关心这个新值

🧠 总结：

❌ 不要试图用委托实现 GoF 的模板方法模式
❌ 被委托类不能访问装饰器中重写的属性或方法
✅ 正确做法：若需共享状态，应显式传递上下文或使用闭包

此外，Kotlin 还支持属性委托，允许我们将属性的 getter/setter 逻辑外放到独立对象中，进一步提升复用性。这属于另一套机制，不在本文展开。

5. 总结

Kotlin 的接口委托是一项强大的语言特性，它使得“组合优于继承”的设计原则得以以极简语法落地。

🔑 主要收益：

减少继承带来的紧耦合
快速构建装饰器、代理、聚合服务
提高代码可读性和可维护性

📌 使用建议：

多用于封装第三方库或不可变类
注意区分委托与继承的行为差异
结合构造注入提升灵活性

完整示例代码已托管至 GitHub：https://github.com/Baeldung/kotlin-tutorials/tree/master/core-kotlin-modules/core-kotlin-lang-oop-2

建议集合并在日常开发中尝试替代不必要的继承结构，你会逐渐体会到它的简洁之美。

Persistence

REST

Security