Guillaume Laforge谈Groovy和DSL

受访人 Guillaume Laforge 采访人 苑永凯 发布于 2007年12月9日 下午8时26分

社区

Ruby,

Java

主题

动态语言,

领域特定语言

标签

Grails,

JRuby,

Ruby on Rails,

Groovy

概要
Groovy项目经理Guillaume Laforge论述了Groovy的发展历程、Groovy与Java的关系、Groovy在Java开发的地位、Groovy与Ruby的比较、如何使用Groovy实现DSL（domain-specific languages，领域特定语言）以及Groovy未来发展的重心。

个人简介
作为Groovy官方的项目经理，Guillaume Laforge将他的业余时间用在了为Groovy社区营造一个完善、敏捷的环境上，并且于一年前发起了Grails项目——基于Groovy和 Spring的Web框架。Guillaume同时也是一位软件架构师和开源顾问，供职于OCTO科技——一家专注于软件架构和信息系统的法国咨询公司。

这里是位于QCon(InfoQ和JAOO组织的技术大会)的Floyd Marinescu和Guillaume Laforge。Guillaume，可以向我们做一个简短的自我介绍吗？

我叫Guillaume Laforge，Groovy团队的项目经理，同时也是JSR 241规范的领导者，JSR 241规范制定了Groovy编程语言的标准。在我的职业生涯里，我是OCTO科技公司的软件架构师，OCTO科技是一家专注于软件架构和敏捷方法学的咨询公司，这也是我为什么乐意参加由InfoQ组织的QCon会议的原因。

Guillaume，是你拯救了Groovy。

是的，几年前Groovy项目一直停滞不前，毫无进展，我们需要有所措施。自从前任项目经理离开 Groovy去参与其它项目，我便接手了项目的领导。我尝试吸引新的开发人员加入，以为项目和社区注入新的活力。我认为努力的结果是相当好的，因为在过去的一个月和过去的一年里，Groovy和Grails都发生了很多变化，而且在未来的时间里你可以看到更多的惊喜。

为什么对于Java来说Groovy是重要的？为什么你为Groovy项目投入了如此多的私人时间？

当初，在我加入Groovy项目之前的两个月里，我一直在编写一个应用程序，用户通过它可以在界面中定制一些窗口小部件（widgets）。最初你只能通过Java来创建它们，并且使用时必须重新部署应用程序而不能在运行中动态地完成创建。这的确让我非常厌烦，我想“如果Java中能提供脚本以支持动态创建就好了”。这时Groovy出现了，我看着它想道：“哦，这太有趣了，我要把它整合到我的Java应用程序中去”。我将业务逻辑、窗口小部件和一些配置项暴露（externalize）至Groovy程序中，然后通过XML传回Java程序，并使用一些编程约束来配置应用程序或者做得更多。如果你在暴露业务逻辑，就可以进一步借助Groovy可塑的语法和动态特性创建自有的领域特定语言。

你认为Groovy最适合用在Java项目的那些地方？

我想到一个案例，美国有一家很大的保险公司，财富杂志评出的世界500强之一，曾经构建了一个非常庞大的保险应用软件来处理健康保险以及其它保险的风险，其中用了大约45000行Groovy程序编写所有的业务逻辑——所有执行动作的规则以及如何计算某个产品或者保险单的风险。公司里的业务专家们甚至也亲手参与编写了一些规则。能将业务逻辑从Java开发组编写的代码中提取出来是相当有意义的，这使得开发人员和业务专家可以一起协作。这相当有趣，也是一个很好的用例，它说明了你应该如何在Java中使用Groovy。我认为我们会看到越来越多类似的在Java 应用程序中使用脚本语言或者动态语言的例子。

Groovy在Java还有没有其它好的用处？

你可以将Groovy用在很多领域，例如你可以用它做脚本任务（scripting tasks），就像在Linux上使用其它脚本语言那样。有趣的是，你不仅可以像使用其它脚本语言那样使用Groovy，而且可以使用所有能得到的 Java库。假如你有一些处理特定业务的Java库，现在想在Groovy中重用它们来解析一些文件或者来自遗留系统的东西，这可以轻松做到。你甚至还可以用Groovy构建一些小型应用的原型。

三个主要的用例是脚本任务，集成Groovy到Java应用程序中来外部化我前面提到的东西，还有编写完整的（full blown）应用。我想到了另外一个例子：法国司法行政部在构建应用的时候用到了Groovy。这个应用包含一个UML模型——其中存放着法官、法庭和其它各种各样的领域对象，都是通过UML设计得到的——提取为XML格式的XMI模型。通过使用Groovy模板和Groovy胶水(glue)程序，他们创建出了应用程序所需的所有内容，如JSP页面、应用程序的流程（从哪个页面跳转到哪个页面，从这个线程动作中输出结果到哪个视图）。最终的应用中没有一行 Groovy代码，但是他们借助Groovy加快了开发速度。

从哪些方面能够明显地看出Groovy正在被Java社区所采用？

Groovy得到了很好的使用，因为我们已经有了许多令人感兴趣的Groovy商业用例。尤其当我们发布了1.0版本之后，我们得到了更多的使用者，订阅我们邮件列表的用户大概是以往的两倍多，越来越多的下载量还有越来越多的人跑来咨询问题。你可以看出这其中有很多新用户，因为他们的问题差不多都是“我该怎么做（各种各样的事情）？”。可以看到自从我们发布了1.0版本，我们取得了成功。而且如果你仔细观察blog网络社区（blogosphere），就会看到每天都有很多关于Groovy和Grails的文章，这有点儿疯狂，不过确实发展显著。甚至在类似于“你更喜欢哪种脚本语言？”的调查中，Groovy也通常都名列榜首。我为成功的来临感到愉悦满足。

为什么Java社区开始关注脚本语言了？

这非常有趣，因为脚本语言已经存在很长一段时间了，事实上那些语言过去一直是作为独立的普通语言来使用的，并没有和Java结合起来。现在有了很大的不同，因为在JVM上有很多可用的语言，所以你可以混合和协调不同的语言，分离不同的程序元素，使用更有表达力的方式定义规则。当然我们也可以看到，脚本语言倍受关注与Ruby和Ruby on Rails的成功有着重要关系。我不能确切地告诉你为什么脚本语言开始受到关注，但是我认为JVM之上的脚本语言的出现，还有围绕在Ruby和其它明星脚本语言周围的讨论都起到了作用。

说到了Ruby，现在看来当Java开发人员想编写脚本的时候，似乎有两个流行的平台可供选择。那应该如何在Groovy和JRuby之间做出选择呢？

对这个问题，我得出一个规律。如果你会使用 Java，那就选择Groovy，因为它的语法与Java相似，而且还可以和Java平台以及Java库无缝集成。Groovy有着和Java相同的面向对象模型、相同的库，还有相同的正则表达式。如果你选择JRuby以便继续停留在JVM上，那选择JRuby之前最好你已经熟悉了Ruby。例如如果有些人精通Ruby，那他们可能直接会选择JRuby。但是如果他们想与Java紧密集成，那么最好选择Groovy，因为它与Java有完全相同的对象模型，这两个不同的语言，不同的范式之间不存在阻抗不匹配（impedance mismatch）。所以我的原则就是：如果你了解Ruby，那么使用JRuby；如果你更喜欢类Java的语言，那就选择Groovy。

你注意到Groovy使得DSL编程在Java中变得流行了吗？

是的，我注意到了。因为Groovy所有的动态特性使得编写类似“3.euros”、“48.dollars”或者“3.days.ago”的表达式变得很容易。你能够编写表达力非常强的东西；你能创建对专业领域、业务概念等进行建模的迷你语言（mini-languages）。虽然已经有了“IF”、“FOR”和“WHILE”循环等控制结构，只要你愿意，你还能创建属于自己的控制结构，Groovy在这方面非常灵活。我认为，那些试图将Ruby嵌入到应用程序业务规则中的人们，更趋向于用一种更简单的语言来对专业领域进行建模，业务人员和开发人员共同分享包含了业务描述的隐喻，使协作更加容易。了解如何使用动态语言为建模和领域定义特定语言是相当让人感兴趣的。

动态语言的哪些特性使得它们比Java更适合定义DSL？

Java属于静态类型语言，使用Java你需要编译器——在Groovy中也有一个编译器——确实是这样的，当你编译Java代码的时候，所有的东西都被编译器硬连接（hard-wired）起来。所以你不可能轻易地拦截方法调用、属性访问或者重写（overwrite ）类似操作一样的东西。这非常不灵活，即使你可以编写一些连续接口（fluent interfaces）来使得Java代码更易读，你通常还会有一些样板代码（boilerplate technical code）[译注：样板代码指的是在程序中重复出现的极其类似的代码块，这部分代码往往与业务无关，而且又必不可少，比如异常处理、日志记录、应用环境相关的数据传递和持久化等等。这些代码往往编写费劲而且可读性差难以维护（例如异常处理代码块）。]影响可读性，并且通常不会有业务人员站在你后面：“嗨，这个规则不应是这样的，而应该是那样”。然而从另一方面，使用动态语言，你可以捕获方法加入方法拦截，给已存在的JDK类或者数值加入新的方法，就像我前面提到的例子那样“3.dollars”就得到了一些钱。在Java中不可能这样做——3仅仅是简单类型，你不能在上面做文章来创建有用的东西。所以最终通过动态语言的元编程工具（这是Java中所没有的），你完全可以发挥想象创建一个带有新约束的语言。正因为它的强大功能，Java才会禁止这么做。

Groovy社区当今所面临的最重要的问题是什么？

我认为目前影响Groovy普及的最大问题是缺少工具支持，尤其是IDE支持，因为Java开发者往往习惯于使用快捷键ctrl-space带来的代码自动完成（code completion）功能，而不必去查找JavaDoc或者APIs的相关文档。2007年我们工作中很重要一个方面就是提供工具支持，而且我们已经拥有了一个较大的团队从事Eclipse插件开发，在接下来的几周或几个月里，就可以使用具有Groovy代码自动完成功能的Eclipse插件，使得 Eclipse中编写Groovy代码变得更加容易。

JetBrains的工作人员想在IntelliJ IDE中添加对Groovy的支持，他们为此已经跟我取得了联系。正如大家所知，他们非常擅长为语言提供杰出的支持，比如JavaScript和 Ruby，我也确信他们能够为Groovy提供很多令人惊奇的功能，比如代码自动完成，甚至重构。有了IDE的强力支持，你可以混合和协调地使用Java 和Groovy而且包括重构功能。这确实是今年我们不得不关注的工作，并且已经有了显著的进展，在年底之前我们应该会得到一些优良的工具支持。总之这绝对是我们需要继续努力的主要方面。

你特别喜欢哪两本计算机书籍？

《程序员修炼之道（Pragmatic Programmer）》是我特别喜欢的书籍之一——它确实是我喜欢阅读的著作之一。实际上我还想到了另外两本，一本是《Groovy实战》，我是该书的合著者之一，自然对其有一点儿偏向，不过它的确是一本好书。如果你在寻找一本关于Groovy的参考书，想了解语言的所有内部工作方式、类库以及编程工具，它就是一本非常棒的书。如果非要提及第三本，那就是由Graeme Rocher撰写的讨论Web框架Grails的《Grails权威指南》。

 

1. 返回顶部

   看不了

   2007年12月11日 下午11时44分 发表人 Ali Yang

   如题

   回复

2. 返回顶部

   Re: 看不了

   2007年12月12日 上午3时24分 发表人 zhang zhidda

   如题

   开卷有益

   回复

3. 返回顶部

   Re: 看不了

   2007年12月14日 上午12时40分 发表人 michael li

   如题

   开卷有益

   他的意思是:视频文件无法播放。

   回复

4. 返回顶部

   Re: 看不了

   2007年12月17日 下午7时8分 发表人 陈 山

   感谢，infoQ, 感谢译者总给我们带来新的东东 找个小bug "不如异常处理、日志记录、应用环境相关的数据传递和持久化等等。" 这句里的 “不如”==“比如|例如”？

   回复

5. 返回顶部

   Re: 看不了

   2007年12月18日 下午5时19分 发表人 Xiaogang Guo

   谢。 看不了可能要刷新一下页面。

   回复

• 更早的 >