本文旨在探讨如何通过Groovy的闭包特性，将功能相似但条件判断逻辑不同的重复方法合并为一个通用方法。我们将演示如何构建一个可配置的 `waitUntil` 方法，它接受一个闭包来封装动态的条件检查，从而有效减少代码冗余，并优化了在循环中创建临时对象的潜在性能问题。
在软件开发中，我们经常会遇到这样的场景：多个方法执行着几乎相同的操作流程，但它们的核心差异仅在于等待某个条件满足的具体判断逻辑。这种模式往往导致代码冗余和维护困难。例如，考虑以下两个Groovy方法：
def someCondition = false
def method1() {
while(!someCondition) {
def connectionStatus = getConnectionStatus() // return 200, 404, etc.
if (connectionStatus == 200) {
someCondition = true
} else {
println "repeat until connection is 200"
sleep 15
}
}
}
def method2(){
while(!someCondition) {
def result = getResult() // A, B, C, etc.
if (result in ["A", "B", "C"]) {
someCondition = true
} else {
println "waiting until result is either A, B, or C"
sleep 15
result = getResult() // call again to check if result changed
}
}
}这两个方法都包含一个 while 循环，用于等待某个条件变为真，并在每次检查失败后暂停一小段时间。它们的主要区别在于 if 语句内部的条件判断逻辑。method1 检查 connectionStatus 是否为 200，而 method2 检查 result 是否在 ["A", "B", "C"] 列表中。这种重复的结构显然可以通过抽象来优化。
利用闭包实现通用等待机制
Groovy的闭包（Closure）提供了一种优雅的方式来封装代码块并将其作为参数传递。我们可以利用这一特性，创建一个通用的 waitUntil 方法，将具体的条件判断逻辑作为闭包传入。
首先，我们定义一个基础的 waitUntil 方法，它接受一个返回布尔值的闭包作为 test 参数：
def waitUntil(int sleepMs = 100, int maxRetries = 60, Closuretest) { int retries = 0 while (retries++ < maxRetries && !test()) { println "尝试 ${retries}/${maxRetries} 次失败，等待 ${sleepMs} 毫秒后重试..." Thread.sleep(sleepMs) } if (retries > maxRetries) { println "已达到最大重试次数，条件未满足。" return false // 或者抛出异常 } println "条件已满足！" return true }
这个 waitUntil 方法包含以下参数：
- sleepMs (int, 默认 100): 每次重试失败后暂停的毫秒数。
- maxRetries (int, 默认 60): 最大重试次数。
- test (Closure
): 一个闭包，它不接受参数并返回一个布尔值。当此闭包返回 true 时，表示条件已满足，等待结束。
现在，我们可以使用这个通用方法来替代之前的 method1 和 method2：
// 模拟获取连接状态
def getConnectionStatus() {
// 实际应用中可能是网络请求
[404, 200, 404].random() // 随机返回状态码
}
// 模拟获取结果
def getResult() {
// 实际应用中可能是某个计算结果
["X", "Y", "A", "Z"].random() // 随机返回结果
}
// 替代 method1 的调用
println "等待连接状态为 200..."
waitUntil(sleepMs: 1000, maxRetries: 10) {
getConnectionStatus() == 200
}
// 替代 method2 的调用
println "\n等待结果为 A, B 或 C..."
waitUntil(sleepMs: 500, maxRetries: 20) {
getResult() in ["A", "B", "C"]
}通过这种方式，我们成功地将重复的等待逻辑抽象到一个方法中，而将变化的条件判断逻辑通过闭包动态注入。
优化闭包参数传递与性能考量
在上述实现中，如果闭包内部需要引用一些外部数据（例如 ["A", "B", "C"] 这样的列表），并且这个闭包会被频繁调用，那么每次调用时都重新创建这个列表可能会带来轻微的性能开销，尤其是在长时间运行或高频率调用的场景下。为了避免这种情况，我们可以将这些外部数据作为参数传递给 waitUntil 方法，并进一步传递给闭包。
优化后的 waitUntil 方法可以接受一个额外的参数 expectedValue，并将其作为参数传递给 test 闭包：
def waitUntil(Object expectedValue, int sleepMs = 100, int maxRetries = 60, Closuretest) { int retries = 0 while (retries++ < maxRetries && !test(expectedValue)) { // 将 expectedValue 传递给闭包 println "尝试 ${retries}/${maxRetries} 次失败，等待 ${sleepMs} 毫秒后重试..." Thread.sleep(sleepMs) } if (retries > maxRetries) { println "已达到最大重试次数，条件未满足。" return false } println "条件已满足！" return true }
现在，调用方式也需要相应调整，闭包可以使用 it 关键字来引用传入的参数：
// 模拟获取连接状态
def getConnectionStatus() {
[404, 200, 404].random()
}
// 模拟获取结果
def getResult() {
["X", "Y", "A", "Z"].random()
}
// 示例：等待连接状态为 200
println "等待连接状态为 200 (优化版)..."
waitUntil(200, sleepMs: 1000, maxRetries: 10) { expected -> // expected 参数接收 200
getConnectionStatus() == expected
}
// 示例：等待结果为 A, B 或 C
println "\n等待结果为 A, B 或 C (优化版)..."
waitUntil(["A", "B", "C"], sleepMs: 500, maxRetries: 20) { expectedList -> // expectedList 接收列表
getResult() in expectedList
}通过这种改进，像 ["A", "B", "C"] 这样的列表只在 waitUntil 方法调用时创建一次，而不是在每次闭包执行时都创建，从而提高了效率。
注意事项与总结
- 错误处理： 在实际应用中，waitUntil 方法可能需要更健壮的错误处理机制，例如在达到最大重试次数后抛出特定异常，而不是简单地返回 false。
- 线程安全： 如果 getConnectionStatus() 或 getResult() 等方法涉及共享状态或外部资源，需要确保其线程安全性。
- 灵活性： 这种模式非常灵活，不仅限于等待外部资源，还可以用于等待内部状态的改变、UI元素的出现等多种场景。
- 代码可读性： 尽管引入了闭包，但由于其简洁的语法和强大的表达能力，这种重构通常能提高代码的可读性和维护性。
通过利用Groovy的闭包特性，我们能够有效地将相似方法的重复逻辑进行抽象和封装，创建出高度可复用且灵活的通用方法。这不仅减少了代码冗余，提高了开发效率，还在一定程度上优化了潜在的性能问题，是Groovy编程中值得推崇的一种设计模式。
