答案。

在Kotlin中，行为委托是通过关键字by在类的签名中实现的。这允许将接口（或多个接口）的方法调用自动传递给其他实现对象，从而减少样板代码并简化组合。

问题的历史

接口委托的出现是为了解决多重继承的限制和缺陷。这是"优先组合而不是继承"的理念——委托行为而不依赖于类的层次结构。这一思想借鉴自组合更为流行的语言（例如Go，Scala）。

问题

在Java及其他语言中，通常需要手动创建接口并实现每个方法，将逻辑传递给另一个字段（对象适配器模式），而当方法数量增加时，这很快就会过时。

解决方案

Kotlin允许通过by以声明方式委托接口：

interface Logger {
    fun log(msg: String)
}
class ConsoleLogger: Logger {
    override fun log(msg: String) = println(msg)
}
class Service(logger: Logger): Logger by logger {
    fun doWork() {
        log("工作开始")
        // ...
    }
}
val service = Service(ConsoleLogger())
service.doWork()

所有Logger的方法都通过提供的logger对象实现，Service类中不需要显式重写或代理方法。

关键特性：

允许将接口实现与使用分开，减少代码重复
委托比继承更灵活，可以处理多种行为
支持更好的SOLID实践

设问陷阱。

如果在Service类中添加具有相同签名的自定义接口方法，会发生什么？

自定义实现"覆盖"了委托的实现——也就是说，类中显式定义的方法优先：

class Service(logger: Logger): Logger by logger {
    override fun log(msg: String) = println("前缀: $msg")
}

一个类能否将多个接口委托给不同对象？

可以，类可以实现并将多个接口委托给不同的对象，但每个接口只能委托给一个对象：

class Service(
    logger: Logger,
    tracker: Tracker
): Logger by logger, Tracker by tracker

接口委托与通过by的属性委托有什么区别？

接口委托将接口的所有功能实现传递给另一个对象。
属性委托（property delegation）将对get/set的工作委托给特定类型的delegated对象（ReadOnlyProperty，ReadWriteProperty）。

常见错误和反模式

委托过大的接口（违反ISP）
同时使用显式实现和委托（不期望的行为）
尝试将接口委托与父类的继承结合，忽略方法解析顺序

生活中的例子

负面案例

类手动实现接口，每个方法调用代理，当添加新方法时忘记更新代理，从而导致错误。

优点：

明确控制逻辑

缺点：

高错误风险，样板代码
当接口扩展时，扩展能力差

正面案例

使用语言层面的委托，仅非标准方法在类内部实现，新功能可以在无需大幅更改的情况下添加。