Groovy 中的 with

Java与Groovy闭包技术对比
本文通过对比Java和Groovy中闭包的应用,详细介绍了如何使用Java的PrintIndependenceDay示例来实现日期打印功能,并展示了Groovy中闭包的特性与使用方法。通过代码示例和解析,深入探讨了闭包在Java和Groovy中的不同实现方式及其实现逻辑。

in Java 

 

// PrintIndependenceDay.java

import java.util.Calendar;
import java.util.Date;

public class PrintIndependenceDay {

  public static void main(String[] args) {
    Calendar calendar = Calendar.getInstance();
    calendar.clear();
    calendar.set(Calendar.MONTH, Calendar.JULY);
    calendar.set(Calendar.DATE, 4);
    calendar.set(Calendar.YEAR, 1776);
    Date time = calendar.getTime();
    System.out.println(time);
  }
}

 in Groovy:

 

 

// PrintIndependenceDay.groovy

def calendar = Calendar.instance
calendar.with {
  clear()
  set MONTH, JULY
  set DATE, 4
  set YEAR, 1776
  println time
}

 每个 Groovy闭包有个与其关联的delegate(代理人).

 

 

// define a closure
def myClosure = {
  // call a method that does not exist
  append 'Jeff'
  append ' was here.'
}

// assign a delegate to the closure
def sb = new StringBuffer()
myClosure.delegate = sb

// execute the closure
myClosure()

assert 'Jeff was here.' == sb.toString()

 换一种写法:

 

 

def closure = {
  clear()
  set MONTH, JULY
  set DATE, 4
  set YEAR, 1776
  println time
}
def calendar = Calendar.instance
closure.delegate = calendar
closure()

 Another bit of info that is missing here is the strategy that a closure uses to decide when to send method calls to the delegate. Each Groovy closure has a resolveStrategy associated with it. This property determines how/if the delegate comes in to play. The 4 possible values for the resolveStrategy are OWNER_FIRST, DELEGATE_FIRST, OWNER_ONLY and DELEGATE_ONLY (all constants defined in groovy.lang.Closure). The default is OWNER_FIRST. Consider the owner to be the "this" wherever the closure is defined. Here is a simple example...

 

 

 

class ResolutionTest {
    
    def append(arg) {
        println "you called the append method and passed ${arg}"
    }
    
    def doIt() {
        def closure = {
            append 'Jeff was here.'
        }
        
        def buffer = new StringBuffer()
        
        closure.delegate = buffer
        
        // the append method in this ResolutionTest
        // will be called because resolveStrategy is
        // OWNER_FIRST (the default)
        closure()
        
        // give the delegate first crack at method
        // calls made inside the closure
        closure.resolveStrategy = Closure.DELEGATE_FIRST
        
        // the append method on buffer will
        // be called because the delegate gets
        // first crack at the call to append()
        closure()
    }
    
    static void main(String[] a) {
        new ResolutionTest().doIt()
    }
}

 运行结果:

you called the append method and passed Jeff was here.

 

 来源:

http://java.dzone.com/news/getting-groovy-with-with

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

<think>嗯,用户询问的是Groovy中var的关键字使用。根据引用内容,Groovy的语法确实融合了Java特性,但引用并未直接提到var,需要结合Groovy动态语言特性来推导。 用户可能刚从Java转向Groovy,注意到两者都有var但不确定差异。需要强调Groovy的var是可选类型声明,这点和Java的局部变量类型推断类似但更灵活。 引用[3]提到Groovy编译后实现GroovyObject接口,这说明var声明的变量在运行时仍是动态类型。引用[2]关于闭包delegate的机制也暗示了变量解析的灵活性,这与var的弱类型特性一致。 用户可能遇到的实际痛点是:在Groovy脚本里用var定义变量后,发现IDE没有像Java那样提供精确的类型提示。这正好对应注意事项中的工具支持问题。 需要提醒单行多变量声明的陷阱,这是实际编码时容易踩的坑。比如var a=1, b="text"这种写法,在Java会报错但在Groovy能运行,可能导致后续代码出现ClassCastException。 生成的问题要偏向实用场景:性能影响对脚本开发很重要,类型推导机制关系到调试效率,而IDE支持则是日常开发体验的关键。用户没问但应该想知道的是"什么时候不该用var"——比如公共API定义时显式类型更安全。 </think>在Groovy语言中,`var` 关键字是用于**局部变量类型推断**的特性,其核心规则和注意事项如下: --- ### 一、`var` 的使用与特性 1. **类型推断** `var` 允许编译器根据赋值表达式自动推断变量类型,无需显式声明类型。例如: ```groovy var list = [1, 2, 3] // 推断为 ArrayList<Integer> var message = "Hello" // 推断为 String ``` *等效于显式声明*: ```groovy List<Integer> list = [1, 2, 3] String message = "Hello" ``` 2. **动态类型限制** - `var` **仅用于局部变量**(方法内或代码块内),不能用于类字段、方法参数或返回值类型。 - 变量类型在初始化时确定后**不可更改**(静态类型特性),例如: ```groovy var num = 10 num = "text" // 编译错误!类型已固定为 Integer ``` 3. **必须初始化** `var` 变量必须在声明时直接赋值,否则编译失败: ```groovy var value; // 错误:缺少初始化 var value = null // 可行,但推断为 Object 类型 ``` 4. **与 `def` 的区别** | 特性 | `var` | `def` | |--------------|---------------------------|---------------------------| | **类型** | 静态类型(编译时确定) | 动态类型(运行时可变更) | | **作用域** | 仅局部变量 | 局部变量、类字段、方法参数 | | **赋值** | 必须初始化 | 可不初始化(默认为 `null`)| ```groovy def dynamicVar = 10 dynamicVar = "Text" // 合法,动态类型允许变更 var staticVar = 10 staticVar = "Text" // 非法,类型已固定 ``` --- ### 二、使用场景与示例 1. **简化复杂类型声明** 适用于泛型集合等冗长类型: ```groovy var users = new ArrayList<Map<String, Object>>() // 避免重复书写完整类型 ``` 2. **循环变量简化** ```groovy for (var i = 0; i < 10; i++) { println i } ``` 3. **try-with-resources** ```groovy try (var reader = new FileReader("test.txt")) { println reader.read() } ``` --- ### 三、注意事项 1. **可读性权衡** 过度使用 `var` 可能降低代码可读性,尤其在复杂逻辑中。 **推荐**: ```groovy var names = ["Alice", "Bob"] // 类型明显(List<String>) ``` **避免**: ```groovy var data = parseJson(response) // 不清楚 data 的实际类型 ``` 2. **工具支持** IDE 的代码提示可能因类型推断而受限,显式声明类型有助于增强工具链支持[^3]。 3. **单行多变量禁止** Groovy 不允许在同一行用 `var` 声明多个变量: ```groovy var a = 1, b = 2 // 编译错误 ``` --- ### 四、总结 | **关键点** | **说明** | |------------------|--------------------------------------------------------------------------| | **类型安全性** | 提供静态类型检查,避免运行时类型错误 | | **代码简洁性** | 减少冗余类型声明,提升编写效率 | | **作用域限制** | 仅限局部变量,不可用于类成员或方法签名 | | **与 `def` 对比**| `var` 为静态类型推断,`def` 为动态类型占位符 | > ⚠️ **最佳实践**:在类型明显(如字面量赋值、构造对象)且不影响可读性时使用 `var`,复杂逻辑优先显式声明类型。 --- ### 相关问题 1. Groovy 中 `def` 关键字的动态类型机制如何影响运行时性能? 2. 如何在 Groovy 闭包内安全使用类型推断变量(如 `var`)以避免作用域混淆[^2]? 3. Groovy 的静态编译(`@CompileStatic`)对 `var` 的类型推断有何强化作用? [^1]: Groovy 特性总结与注意事项 [^2]: Groovy 闭包与委托机制 [^3]: Groovy 动态特性与编译实现对比
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值