Groovy 闭包委托：delegate 与 owner

Groovy 闭包不仅是一段代码，它更是一个携带上下文的对象。理解闭包中的 this、owner 和 delegate 三者关系，是掌握 Groovy 元编程和 DSL（领域特定语言）开发的关键。特别是 delegate，它赋予了闭包在不同对象上下文中“动态切换”的能力。

1. 理解三大核心属性

Groovy 闭包对象中有三个至关重要的属性，决定了方法调用和变量访问的解析策略。

核心区别：this 总是看“大环境”（类），owner 看“直接环境”（可能是嵌套闭包），delegate 是“代理人”，我们可以指定它代表谁。

2. 验证默认行为

在默认情况下，owner 和 delegate 指向同一个对象。我们通过代码来验证这一点。

新建一个名为 ClosureScope.groovy 的文件，输入以下代码：

class OuterClass {
    def outerMethod() {
        def innerClosure = {
            println "this: " + this.getClass().name
            println "owner: " + owner.getClass().name
            println "delegate: " + delegate.getClass().name
        }
        innerClosure()
    }
}

def outer = new OuterClass()
outer.outerMethod()

运行脚本，观察输出结果。你会发现 owner 和 delegate 都指向了 OuterClass，这证明了它们的默认一致性。

3. 动态修改委托

delegate 的强大之处在于它是可变的。我们可以将闭包的“代理”切换到任何一个对象，从而在该闭包中调用新对象的方法。

1. 定义一个辅助类 Writer，包含一个 write 方法。
2. 定义一个闭包，内部调用 write()。
3. 修改闭包的 delegate 属性指向 Writer 实例。
4. 执行闭包。

输入并运行以下代码：

class Writer {
    def write() {
        println "Writer is writing..."
    }
}

def closure = {
    // 此处并未定义 write 方法
    write() 
}

closure.delegate = new Writer()

// 设置解析策略为 DELEGATE_FIRST，稍后详解
closure.resolveStrategy = Closure.DELEGATE_FIRST

closure()

观察控制台，输出了 "Writer is writing..."。这说明闭包在执行时，不是去寻找自己或定义者身上的方法，而是找到了 delegate 对象身上的方法。

4. 掌握解析策略

仅仅改变 delegate 是不够的，还需要告诉 Groovy 在查找方法时的“优先级”。这就是 resolveStrategy 的作用。Groovy 提供了多种策略，最常用的是以下两种：

为了直观理解查找逻辑，我们可以参考以下流程图：

5. 实战构建简单的 DSL

结合 DELEGATE_FIRST 策略，我们可以构建一个流畅的配置脚本。假设我们要配置一个 Server 对象。

编写如下代码：

class Server {
    String ip
    int port

    def run(Closure config) {
        // 将闭包的委托指向当前 Server 实例
        config.delegate = this
        // 关键步骤：设置为优先查找委托
        config.resolveStrategy = Closure.DELEGATE_FIRST
        // 执行配置闭包
        config()
    }

    String toString() {
        return "Server [ip=${ip}, port=${port}]"
    }
}

// 使用 DSL 风格配置
def myServer = new Server()

myServer.run {
    // 这里的 ip 和 port 实际上是 myServer 的属性
    // 虽然看起来像在闭包内直接赋值，但通过 delegate 路由到了 Server 对象
    ip = "192.168.1.1"
    port = 8080
}

println myServer

分析执行流程：

1. myServer.run { ... } 调用方法。
2. run 方法内部将闭包的 delegate 设置为 this（即 myServer 实例）。
3. 策略设置为 DELEGATE_FIRST。
4. 闭包执行时遇到 ip = ...。
5. Groovy 查找 delegate（即 Server 对象），发现存在 ip 属性，执行赋值。

如果没有 DELEGATE_FIRST，Groovy 会默认去 owner（也就是定义闭包的脚本对象）里找 ip，找不到才会去 delegate，这在构建 DSL 时会导致逻辑混乱。

6. 理解 owner 的嵌套特性

delegate 是动态的，而 owner 是静态的（由代码结构决定）。特别是在闭包嵌套闭包时，owner 指向直接包含它的那个闭包。

输入以下代码观察区别：

def outer = {
    def mid = {
        def inner = {
            println "inner owner: " + owner.getClass().name
        }
        inner()
    }
    mid()
}

outer.delegate = new Object() // 改变最外层委托
outer()

查看输出结果。尽管我们修改了 outer 的 delegate，inner 的 owner 依然指向的是 mid 这个闭包对象（通常显示为 Closure 类的匿名内部类实例），而不是 outer 的 delegate。这证明了 owner 链是严格按照代码嵌套结构固定的，不受 delegate 修改的影响。