Groovy中利用闭包抽象化相似方法中的条件逻辑-java教程-PHP中文网

Groovy中利用闭包抽象化相似方法中的条件逻辑

心靈之曲

发布： 2025-11-05 14:24:01

原创

567人浏览过

Groovy中利用闭包抽象化相似方法中的条件逻辑

本文探讨了如何通过groovy的闭包特性，优雅地合并那些仅在条件判断逻辑上有所差异的相似方法。通过设计一个通用的等待机制，该机制接受一个返回布尔值的闭包作为条件检查器，我们能够实现代码的高度复用和灵活性。文章详细介绍了如何构建这样的通用方法，并进一步优化了闭包参数传递，以提升性能和代码可读性，最终达到减少冗余、提高维护性的目标。

在软件开发中，我们经常会遇到这样的场景：有多个方法在执行流程上大体相同，但它们的核心差异仅在于判断某个操作是否成功的条件逻辑。如果为每个不同的条件都编写一个独立的方法，会导致大量的代码重复，降低代码的可维护性和可读性。Groovy语言凭借其强大的闭包特性，为解决这类问题提供了一种优雅且高效的方案。

相似方法的挑战

考虑以下两个Groovy方法示例：

def someCondition = false

def method1() {
    while(!someCondition) {
        def connectionStatus = getConnectionStatus() // 返回 200, 404 等
        if (connectionStatus == 200) {
            someCondition = true
        } else {
            println "重复直到连接状态为 200"
            sleep 15
        }
    }
}

def method2(){
    while(!someCondition) {
        def result = getResult() // A, B, C 等
        if (result in ["A", "B", "C"]) {
            someCondition = true
        } else {
            println "等待直到结果为 A, B 或 C"
            sleep 15
            result = getResult() // 再次调用检查结果是否改变
        }
    }
}

登录后复制

这两个方法都包含一个循环，不断检查某个条件，直到条件满足为止，期间会进行短暂停顿。它们的主要区别在于 if 语句内部的判断逻辑：method1 检查连接状态是否为200，而 method2 检查结果是否在特定列表中。这种结构上的相似性表明存在抽象和合并的可能性。

利用闭包实现通用等待机制

Groovy的闭包允许我们将一段代码逻辑作为参数传递给方法。这正是解决上述问题的关键。我们可以设计一个通用的 waitUntil 方法，它接受一个闭包，该闭包负责执行实际的条件检查并返回一个布尔值，指示条件是否满足。

基础 waitUntil 方法

以下是 waitUntil 方法的基本实现，它包含重试机制和休眠时间：

/**
 * 异步等待直到指定条件满足。
 *
 * @param sleep 单次重试失败后的休眠时间（毫秒），默认为1毫秒。
 * @param maxRetries 最大重试次数，默认为10次。
 * @param test 一个返回布尔值的闭包，用于测试条件是否满足。
 *             当闭包返回 true 时，表示条件已满足，等待结束。
 */
def waitUntil(int sleep = 1, int maxRetries = 10, Closure<Boolean> test) {
    int retries = 0
    while (retries++ < maxRetries && !test()) {
        println "第 ${retries}/${maxRetries} 次尝试失败，休眠 ${sleep} 毫秒后重试"
        Thread.sleep(sleep)
    }
    // 如果循环结束时条件仍未满足，可以考虑抛出异常或返回 false
    // 但在这个例子中，我们假设达到最大重试次数后循环自然结束。
}

登录后复制

这个 waitUntil 方法有三个参数：

sleep: 每次重试失败后的休眠时间（毫秒）。
maxRetries: 最大重试次数。
test: 一个 Closure<Boolean> 类型的闭包，它不接受参数，并且预期返回一个布尔值。当此闭包返回 true 时，表示等待条件已满足。

使用示例

现在，我们可以使用这个通用的 waitUntil 方法来替换之前的两个独立方法：

// 假设 getResult() 和 getConnectionStatus() 是已定义的方法
// def getResult() { /* ... */ }
// def getConnectionStatus() { /* ... */ }

// 替换 method2 的逻辑
waitUntil {
    getResult() in ["A", "B", "C"]
}

// 替换 method1 的逻辑 (假设 getConnectionStatus() 存在)
waitUntil {
    getConnectionStatus() == 200
}

登录后复制

我们还可以灵活地调整重试参数：

百度文心百中

百度大模型语义搜索体验中心

查看详情

// 休眠 100 毫秒，默认重试次数
waitUntil(100) {
    getResult() in ["A", "B", "C"]
}

// 休眠 100 毫秒，最多重试 5 次
waitUntil(100, 5) {
    getResult() in ["A", "B", "C"]
}

登录后复制

通过这种方式，我们成功地将重复的等待和重试逻辑抽象出来，只留下不同的条件判断部分作为闭包传入，极大地提高了代码的复用性。

性能优化：避免重复创建对象

在上述示例中，getResult() in ["A", "B", "C"] 这样的表达式会在每次闭包调用时创建一个新的 ["A", "B", "C"] 列表。对于快速循环或长时间运行的任务，这可能会导致频繁的对象创建和垃圾回收负担。为了优化这一点，我们可以将这些“期望值”作为参数传递给 waitUntil 方法，然后由 waitUntil 方法再将它们传递给闭包。

优化后的 waitUntil 方法

/**
 * 异步等待直到指定条件满足，并支持向闭包传递期望值。
 *
 * @param expectedResult 传递给闭包的期望结果值，可以是任意类型。
 * @param sleep 单次重试失败后的休眠时间（毫秒），默认为1毫秒。
 * @param maxRetries 最大重试次数，默认为10次。
 * @param test 一个接受一个参数并返回布尔值的闭包，用于测试条件是否满足。
 *             闭包的参数将是 `expectedResult`。
 */
def waitUntil(Object expectedResult, int sleep = 1, int maxRetries = 10, Closure<Boolean> test) {
    int retries = 0
    while (retries++ < maxRetries && !test(expectedResult)) { // 将 expectedResult 传递给闭包
        println "第 ${retries}/${maxRetries} 次尝试失败，休眠 ${sleep} 毫秒后重试"
        Thread.sleep(sleep)
    }
}

登录后复制

在这个优化版本中，waitUntil 方法多了一个 expectedResult 参数，并且它会将这个参数传递给 test 闭包。在Groovy中，如果闭包只接受一个参数，可以使用隐式参数 it 来引用它。

优化后的使用示例

// 替换 method2 的逻辑，并优化性能
waitUntil(["A", "B", "C"]) { expected -> // 闭包接受一个参数，这里命名为 expected
    getResult() in expected
}

// 或者使用隐式参数 'it'
waitUntil(["A", "B", "C"]) {
    getResult() in it // it 指代传入的 ["A", "B", "C"]
}

// 替换 method1 的逻辑
// 对于简单值，可以直接传递，闭包中直接比较
waitUntil(200) { expectedStatus ->
    getConnectionStatus() == expectedStatus
}

登录后复制

通过这种方式，["A", "B", "C"] 列表只会在 waitUntil 方法调用时创建一次，而不是在每次闭包执行时都创建，从而减少了垃圾回收的压力。