既然可使用属性setter，Delegates.observable有哪些适用场景？

好问题！确实，自定义setter看起来能搞定不少属性变化的场景，但Delegates.observable在一些特定场景下会更顺手，甚至是更优的选择。我来梳理几个最常见的适用场景：

1. 复用跨属性的变化响应逻辑 #

如果多个属性需要执行完全相同的变化后逻辑（比如打日志、通知状态更新），用Delegates.observable可以把逻辑抽成通用的处理器，避免在每个setter里重复写代码。

比如多个属性都需要打印变更日志：

// 抽取出通用的日志逻辑
val logPropertyChange = { prop: KProperty<*>, old: String, new: String ->
    println("[LOG] ${prop.name} 从 $old 变更为 $new")
}

// 多个属性复用同一个处理器
var username by Delegates.observable("Alice", logPropertyChange)
var email by Delegates.observable("alice@test.com", logPropertyChange)
var address by Delegates.observable("123 Main St", logPropertyChange)

如果用自定义setter，你得给每个属性都写一遍field = value+日志代码，冗余度很高。

2. 无侵入的外部监听 #

当你没法修改目标类的代码（比如类来自第三方库、或者是你不想污染的核心业务类），Delegates.observable可以帮你在外部实现属性变化监听，完全不改动原有类的逻辑。

举个例子，假设你用了一个第三方的User类：

// 第三方库的类，无法修改
class ThirdPartyUser(var name: String)

你想监听name的变化，但又不能改ThirdPartyUser的setter，这时候可以用委托包装属性：

// 用observable委托包装，实现外部监听
var currentUser by Delegates.observable(ThirdPartyUser("Bob")) { _, oldUser, newUser ->
    println("用户名从 ${oldUser.name} 变成了 ${newUser.name}")
}

// 当currentUser变化时，自动触发监听
currentUser = ThirdPartyUser("Charlie")

这种场景下，自定义setter根本没法用——总不能去改第三方库的代码吧？

3. 简洁的“纯监听”场景 #

如果你的需求只是监听属性变化，不需要修改赋值逻辑（比如只是通知UI更新、记录状态变更），Delegates.observable的写法比自定义setter更清爽：

对比你的示例代码：

// 用observable：只需要关注变化后的逻辑，不用手动处理field赋值
var foo by Delegates.observable("hello") { prop, old, new ->
    println("foo变了：$old → $new")
}

// 用自定义setter：必须手动写field = value，代码不够聚焦
var bar = "hello"
    set(value) {
        field = value // 这行是冗余的“模板代码”
        println("bar变了：$field → $value")
    }

当逻辑只是监听时，observable让代码更专注于业务逻辑，减少了模板代码。

4. 委托逻辑的组合扩展 #

Kotlin的委托支持组合使用，你可以把Delegates.observable和其他委托（比如Delegates.vetoable、自定义委托）结合，实现更复杂的逻辑，而自定义setter很难做到这种灵活的组合。

比如先验证属性值的合法性，再监听变化：

// 先通过vetoable验证年龄不能为负，再用observable记录变更
var age by Delegates.vetoable(18) { _, _, new ->
    new >= 0 // 不合法的值会被拒绝赋值
}.observable { _, old, new ->
    println("年龄从 $old 变更为 $new")
}

age = 20 // 验证通过，触发监听
age = -5 // 验证失败，不会触发监听

这种组合逻辑如果用自定义setter实现，会把代码搞得很臃肿，而委托的方式则清晰很多。

5. 动态管理监听器（进阶场景） #

默认的Delegates.observable是固定一个处理器，但你可以基于它封装出支持动态添加/移除监听器的委托，让你在运行时灵活调整响应逻辑——这是自定义setter几乎做不到的（除非在setter里维护监听器列表，会把类的内部逻辑搞得很复杂）。

示例封装：

class DynamicObservable<T>(initialValue: T) {
    private val listeners = mutableListOf<(KProperty<*>, T, T) -> Unit>()
    
    // 用observable作为底层委托，触发所有监听器
    var value by Delegates.observable(initialValue) { prop, old, new ->
        listeners.forEach { it(prop, old, new) }
    }
    
    // 动态添加监听器
    fun addChangeListener(listener: (KProperty<*>, T, T) -> Unit) {
        listeners.add(listener)
    }
    
    // 动态移除监听器
    fun removeChangeListener(listener: (KProperty<*>, T, T) -> Unit) {
        listeners.remove(listener)
    }
}

// 使用方式
var counter = DynamicObservable(0)

// 添加第一个监听器
val logListener = { _: KProperty<*>, old: Int, new: Int ->
    println("计数器变化：$old → $new")
}
counter.addChangeListener(logListener)

counter.value = 1 // 触发监听

// 移除监听器
counter.removeChangeListener(logListener)
counter.value = 2 // 不再触发日志

这种动态监听的能力，对于需要灵活调整响应逻辑的场景（比如UI组件的动态订阅/取消订阅）非常有用。

简单总结：如果你的需求是复用逻辑、无侵入监听、组合委托、纯监听场景，或者动态管理监听器，Delegates.observable会是更好的选择；如果只是单个属性的简单赋值+自定义逻辑，自定义setter完全够用。

内容的提问来源于stack exchange，提问作者kptlronyttcna