本文探讨了如何通过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, Closuretest) { int retries = 0 while (retries++ < maxRetries && !test()) { println "第 ${retries}/${maxRetries} 次尝试失败，休眠 ${sleep} 毫秒后重试" Thread.sleep(sleep) } // 如果循环结束时条件仍未满足，可以考虑抛出异常或返回 false // 但在这个例子中，我们假设达到最大重试次数后循环自然结束。 }
这个 waitUntil 方法有三个参数：
- sleep: 每次重试失败后的休眠时间（毫秒）。
- maxRetries: 最大重试次数。
- test: 一个 Closure
类型的闭包，它不接受参数，并且预期返回一个布尔值。当此闭包返回 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, Closuretest) { 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 方法调用时创建一次，而不是在每次闭包执行时都创建，从而减少了垃圾回收的压力。
总结与注意事项
通过Groovy的闭包，我们可以非常灵活地抽象和重用那些仅在条件逻辑上有所差异的方法。这种模式不仅减少了代码重复，提高了可维护性，也使得代码意图更加清晰。
关键点：
- 高阶函数思维： 将条件判断逻辑封装成一个可传递的单元（闭包）。
- 代码复用： 核心的循环、重试、休眠逻辑被集中管理。
- 灵活性： 可以轻松地为不同的场景定制条件、休眠时间和重试次数。
- 性能优化： 通过将期望值作为参数传递给主方法，再由主方法传递给闭包，避免了闭包内部重复创建对象。
在实际应用中，你可能还需要考虑更完善的错误处理，例如在达到最大重试次数后抛出特定异常，或者提供一个回调函数来处理每次重试失败时的日志记录或额外操作。这种基于闭包的模式是Groovy在编写简洁、可维护且功能强大的代码方面的强大体现。
