本文旨在探讨如何通过Groovy的闭包特性，将功能相似但条件判断逻辑不同的重复方法合并为一个通用方法。我们将演示如何构建一个可配置的 `waitUntil` 方法，它接受一个闭包来封装动态的条件检查，从而有效减少代码冗余，并优化了在循环中创建临时对象的潜在性能问题。
在软件开发中，我们经常会遇到这样的场景：多个方法执行着几乎相同的操作流程，但它们的核心差异仅在于等待某个条件满足的具体判断逻辑。这种模式往往导致代码冗余和维护困难。例如，考虑以下两个Groovy方法：
def someCondition = falsedef 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, Closure test) { int retries = 0 while (retries++ maxRetries) { println "已达到最大重试次数，条件未满足。" return false // 或者抛出异常 } println "条件已满足！" return true}
这个 waitUntil 方法包含以下参数：
sleepMs (int, 默认 100): 每次重试失败后暂停的毫秒数。maxRetries (int, 默认 60): 最大重试次数。test (Closure): 一个闭包，它不接受参数并返回一个布尔值。当此闭包返回 true 时，表示条件已满足，等待结束。
现在，我们可以使用这个通用方法来替代之前的 method1 和 method2：
Word-As-Image for Semantic Typography
文字变形艺术字、文字变形象形字
62 查看详情
// 模拟获取连接状态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, Closure test) { int retries = 0 while (retries++ maxRetries) { println "已达到最大重试次数，条件未满足。" return false } println "条件已满足！" return true}
现在，调用方式也需要相应调整，闭包可以使用 it 关键字来引用传入的参数：
// 模拟获取连接状态def getConnectionStatus() { [404, 200, 404].random()}// 模拟获取结果def getResult() { ["X", "Y", "A", "Z"].random()}// 示例：等待连接状态为 200println "等待连接状态为 200 (优化版)..."waitUntil(200, sleepMs: 1000, maxRetries: 10) { expected -> // expected 参数接收 200 getConnectionStatus() == expected}// 示例：等待结果为 A, B 或 Cprintln "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编程中值得推崇的一种设计模式。
以上就是Groovy中利用闭包重构相似条件等待方法的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/989203.html
微信扫一扫 
支付宝扫一扫 
