概述这是Manning Publications 出版的Groovy in Action 第二章中的一个由三部分组成的系列中的第一部分. 这个章节将用很高视角的方式介绍这种语言. 读了这一系列后,你将会由对Groovy的基本原理有个完整的基本理解. 这个章节讲将你揭示Groovy编码的基本面貌,以及它和Java的相似处和不同点. 同时也介绍了一个Groovy的内置特性:assertionts(断言),整部书将会用这个特性去做书中用例程序的自我校验.

---

一首经典乐曲的序曲通常是向听众介绍整部乐章的主题,这个章节也将采用这种模式. 经典作曲家编写出优美的乐章在以后的演奏中会被再次研究,扩展,改变和组合. 在一定程度上,序曲是整部乐章的缩影. 在这个章节中,我将向你介绍许多Groovy语言的基本概念. 但是首先,我们的学习将从了解Groovy的两个特征开始:编码格式和断言. 这个章节中,我们提供了一些程序例子来让你开始认识这种语言.然而,每个例子只有一小部分会被详细的解释,只是能够让你有个开始而已. 如果你想透彻分析每个例子,那么先读完这章,回头再来研究. 序曲可以让你调整适应这乐器,这声音,这音量和座椅. 所以,背靠下,放松,享受这Groovy交响乐.

2.1 基本编码风格

计算机语言在他们的代码感观上往往有一个明显的传统. 例如,一个C程序员在看Java代码时也许不认识许多的关键词,但他们却熟悉大括号的这种布局,操作符,圆括号,注释,声明结束符和样子. 你开始使用Groovy时你也许会无法将它和Java区分开来,当你对这种语言的了解增加时,你会发现从Java转变成这样更加轻量级的,有启发性的,习惯风格的语言很平滑. 我们先来看一些基础的:如何去注释掉代码,比较Java和Groovy的不同,看看他们的相似处,以及为什么Groovy抛弃一些定义语法代码会更加简洁. 首先,Groovy对代码缩进不敏感,但是对代码块遵循这通常的缩进结构时一个好的技术习惯. Groovy通常对多余的空格没有察觉,但对当前声明的换行和独行注释例外. 让我们来看看Groovy编码中的一些风格样子.

2.1.1 注释Grovvy代码

除了第一行的可选的脚本代码外,单行注释和多行注释跟java完全一样.

#!/usr/bin/groovy
		  
		  // some line comment
		 
		  /*
		     some multiline
		     comment
		  */

对于写Groovy注释这有一些提示:

• 这个#! 注释符只能出现在第一行. 它是让Unix shell去定位Groovy启动程序,来运行这些代码.
• // 是注释掉这一单行一直到结束.
• 多行注释要被包围在/* 和*/ 标记里面.
• 包围在 /** 和 */ 里面的Javadoc风格的注释将会受到多行注释一样的对待,但是对Groovydoc的支持会在写作的时候实现. 它会成为对于Groovy来说跟Javadoc对等的东西,有这相同的语法.

然而,Groovy中跟Java相近的语法并非只是注释.

2.1.2 语法的比较

有一些(但不是全部)Groovy代码的样子跟他们在Java里的完全一样. 这经常会导致一些说 Groovy语法是Java语法超集的错误结论. 尽管相似,但其中没有一种语言是另一种的超集. 例如,Groovy目前不支持传统Java的for(init;test;inc)循环. 就像你会在表2.1看到,相当的语法定义会有轻微的不同,(例如,==操作符) 除了这些细微差别外,整个的主要的java语法是Groovy语法的一部分. 这些适应于

• 通常的packaging机制
• 声明(包括package和import声明)
• 类和方法的定义(嵌套类定义除外)
• 控制结构(除了传统的 for(init;test;inc) 循环)
• 操作符,表达式和赋值
• 异常处理
• 常数的声明(有些变化)
• 对象实例,引用和解除对象引用,以及方法调用. 下面是在Groovy中增加的语法:
• 简化了的对Java类访问的新表达式和操作符
• 允许更多的直接声明对象的方式
• 提供了新的控制结构来实现高级的流程控制
• 引入了新的数据类型以及相关的操作符和表达式
• 一切都是对象

总之,包括这些新增的,Groovy很像Java. 这些增加的语法元素使得代码更加紧凑和易懂. 一个有趣的印象是Groovy用丢弃来增加能力.

2.1.3 简约至美

Groovy允许你避免一些Java中必须的语法元素. 忽略这些元素可以使代码更短小,更少的冗余,以及更有表现力. 例如,我们将Java和Groovy对一个字符串进行URL编码的代码进行比较:

Java:
		  java.net.URLEncoder.encode("a b");
		  Groovy:
		  URLEncoder.encode 'a b'

Groovy代码不仅仅是短小,而且是以最简单的方式表达了我们的目的. 通过去掉package前缀,圆括号,以及分号,代码浓缩到了极致. Groovy语言规范(GLS)里总结的避免混淆和优先处理规则确保了把圆括号变成可选性的支持. 虽然这些规则是很明确的,但她们并不是总是很直观. 虽然编译器很喜欢,但忽略圆括号做法可能导致误解. 除了在一些微不足道的地方外,我们更喜欢还是保留圆括号. 编译器并不判断你的代码是否有可读性,我们必须自己做到这些.

在第7章中,我们同样会讨论一项可选的用于返回的声明.

就像对待  java. math.BigInteger and BigDecimal 这些类一样,Groovy会自动的导入 .groovy.lang.*, groovy.util.*,java.lang.*, java.util.*, java.net.*, and java.io.*这些包. 这样,我们可以引用这些类而不用声明它们的包名. 这样的使用方法将会贯穿整部书,除非可能导致不明确的或者要指出出处的地方. 请注意Java仅仅自动导入java.lang.*.

这小节向你们介绍了足够的背景知识,这样你们可以更容易的依次集中精力于每个单独的特性. 虽然这些语言特征在书里将会都涉及到,但不会讲的非常详细.可是你需要知晓这些代码一般的格式.

有了这个基础,我们就可以关注这个首要的工具:断言,我们将会使用它去测试这种语言中的每一新代码片段.

2.2 用断言来检查

如果你使用Java 1.4 或者更高版本,你可能对断言很熟悉. 断言测试跟你的程序有关的所有东西是否正确. 通常,他们存在你的代码里来确保你的逻辑没有矛盾,执行一些例如检查在方法开始和返回时的常量,确保函数参数是否有效. 然而,在这本书里,我们将用它来证实一些Groovy的语言特征. 就像在测试驱动模式开发中,一个代码单元做了什么是用测试来最终证实的,在这本书中,断言将用来证实特定的某个Groovy程序的返回值. 我们用断言不仅来显示代码是否能运行,而且还包括运行代码返回的结果. 这一章节将会让你准备好阅读本书余下的部分,会解释断言如何工作的,你如何使用它.

尽管学习一门语言从学习断言开始有点奇怪,但断言确实是我们的第一个停泊处,因为除非你理解了断言,你不能理解任何一个本书的例子. Groovy用 assert 关键字来使用断言. 表 2.1 展示了它们的样子.

让我们一个一个的说.assert(true) 这个显示了断言关键字,表明你需要提供一个表达式用来判断是否正确. assert 1==1

这个显示了断言可以接收一个完整的表达式,不仅仅是常量和简单变量. 不出意外,1 等于 1. 跟Ruby一样但不像Java, 这==操作符指示相等,并非同一. 我们不使用圆括号,因为它们在顶层声明中是可选的. def x = 1 assert x == 1

这句定义变量 x,给它赋予数字1,在被判断的表达式中使用它. 注意我们们没有解释任何关于x的类型. 这def 关键字意味着动态类型. def y = 1 ; assert y == 1

在当前行里判断程序的状态是典型的书写风格. 在一行里写两个声明,用分行分割. 分号是Groovy的声明结束符合. 就像你在前面看到的,在行的结尾处它是可选的.

断言用于多个目的:

• 断言用于显示当前程序的状态,就像在本书的例子中使用的. 之前的断言就显示变量y等于1.
• 断言是注释很好的替代物,因为它们揭示那些假设并同时验证它们. 之前的断言就揭露了(也是代码的注释)假设y的值应该是1. 注释会在没人关注时过期,但断言会一直检查代码的正确性. 它们就像在真实代码里寄居的微小测试单元.

现实生活

大多数我们的例子里都会使用断言,其中一部分用断言做判断的表达式会被讲解,其它一部分会很简单,看看就能理解. 如果你对一个例子的理解有困难,试试去拆分它,想想被讨论过的语言特征,你期望的结果,在运行时用断言检查,在看看我们曾经说过的应该的返回结果是什么, 图2.1将一个复杂的断言语句拆分成了不同的几部分.

这是个极端的例子,我们经常是在一个独立语句里执行这些语句,而且让断言尽量短小. 原理是一致的,然而:这些代码都具有我们准备去演示的功能,这些代码短小,在没有通晓这个主题的详细知识时也很容易理解. 当断言不能让你确信或者不确信本书中一个被验证的表达时,你通常可以将它替换成输出到控制台里. 例如, 像这样的一个断言 assert x == \'hey, this is really the content of x\' 可以替换成用 println x 将x的值输出到控制台. 在这本书里,我们通常时把控制台输出替换成断言,就是让代码自检验. 在这边书中这不是一个通常的表现代码的方式,但我们觉得它保持代码和返回结果更接近,而且有助于测试驱动的开发特征.

断言还有一些更有趣的能够影响我们编码风格的特征. 在6.2.4章节会对此进行深入讲解. 现在我们说明了这个可以用来将Groovy放在显微镜下的工具,你可以开始去发现一些真是特征了.

Thishasbeenpart1ofathree-partseriesexcerptedfromthebookGroovyinActionfromManningPublications.ThesecondinstallmentwillreviewthevariousdatatypesforwhichGroovyhasnativelanguagesupport.ItwillgiveyouafirstimpressionofwhatmakesGroovysospecial