当前,对于Python、Ruby 和Groovy的讨论以及学习正如火如荼。很多爱好者出于各种目的都在积极地开发这3种语言的潜力。Python和Ruby也分别有Java的版本:Jython和JRuby,再加上Groovy,把一些软件初学者,特别是初初弄软件架构的人员搞得在他们这几种语言中无从着手进行选择,本文从面向方面程序设计、分析的角度,帮助初学者对目前很热的这3种语言进行分类,以期这部分读者能顺利地解决对这3种语言的认识问题,同时也解决一些长期以来纠缠不清的理论问题。为了达到这个目的,我们从以下4个方面来进行叙述:
◆Python、Ruby和Groovy都是动态语言
◆元逻辑编程和面向方面的编程
◆Jython、JRuby和Groovy的语言层次分析
◆如何比较经济地使用Python、Ruby和Groovy语言
一、Python、Ruby和Groovy都是动态语言
【动态语言】是指用该语言编写的程序在运行时可以动态地改变程序定义的语言要素的层次结构或内部结构。比如,你可以在运行时用Ruby的反射机制或Groovy的元对象协议(MOP)完成下列编程:
例1:下面是一个Ruby脚本
- #Ruby 程序
- #alias_method:用来记录被覆盖的方法
- #define_method:重新定义一个方法,一般会调用alias_method保存的方法
- #class_eval: 根据传入字符串的值,给类增加一个方法。
- def run_before(m)
- alias_method "__before__#{m}", m
- define_method(m) {|*arg| yield(*arg); send("__before__#{m}", *arg);}
- end
- class Test
- def run
- puts "hello, my run"
- end
- def self.log
- puts "before run"
- end
- end
- class Test
- run_before("run") {log}
- end
- test = Test.new
- test.run
例2:下面是一段Groovy脚本
- //Groovy程序
- package com.groovy;
- class MOPHandler {
- static void main(args) {
- def hndler = new MOPHandler()
- hndler.helloWorld()
- hndler.createUser("Joe", 18, new Date())
- hndler.name
- hndler.metaClass.toString()
- }
- def invokeMethod(String method, Object params) {
- println "MOPHandler was asked to invoke ${method}"
- if(params != null) {
- params.each{ println "\twith parameter ${it}" }
- }
- }
- def getProperty(String property) {
- if (property.equals("name")) {
- print "你用过 name 属性\n"
- }
- println "MOPHandler was asked for property ${property}"
- }
- }
到这里我们必须提出一个比较严肃的问题:像上面我们看到的两个程序一样,这种反射式的编程和时下流行的“面向方面”的程序设计到底式什么样的一个关系呢?
二、元逻辑编程和面向方面的编程
【元逻辑编程】通常是指利用语言本身的各种固有机制,特别是一些语言本身的背景机制进行编程的逻辑机制。比如,反射,又如作用于Java字节码的一些开源工程项目(像ASM)等等。当你对Jython、JRuby 和 Groovy 的jar包进行分析后,你会发现下面的一张表格:
语言对比条目 |
Jython |
JRuby |
Groovy |
语言***版本 |
|
|
|
基本jar包 |
jython.jar 共计:1177KB |
asm- asm-commons- backport-util-concurrent.jar bsf.jar jline-0.9.91.jar jruby.jar 共计:2932030字节 |
groovy-all- 共计:2718KB |
字节码处理 |
无 |
有 |
有 |
与Java的兼容性 |
稍低 |
中等 |
极高 |
元逻辑编程机制 |
有 |
有 |
有 |
开发者支持程度 |
人数少 |
人数中等 |
人数呈上升趋势 |
掌握难度 |
及其容易 |
不易掌握 |
要懂Java |
Web开发框架惯例 |
无 |
Rails |
Grails |
可编译特性(Java) |
可以 |
可以 |
可以 |
原生AOP支持 |
不支持 |
偏向于不支持 |
支持 |
这份简单的表格为我们提供了很多有用的信息,在这里我们主要关注——这3种语言的“元逻辑编程”和“面向方面编程(AOP)”两项内容。
首先我们要清楚元逻辑编程并不是AOP,当前很多的开发者将元逻辑编程和AOP混淆了起来,比如,上面例子1中有些开发者就将它认为是AOP的例子,这里我们来澄清一下相关认识:
1、AOP本身强调的是:连接点、切点、通知以及方面,并且AOP很在乎由这些AOP编程机制带来的类层次结构的改变。这一点对于无论你用的是静态织机还是动态织机都一样。
2、我们不能把类似Java的动态代理机制就认为是AOP的本真编程,比如,例子2中这个Groovy的程序由一个子句: new MOPHandler() 就没有被元对象协议捕捉。
因此,我们说:虽然面向方面的分析与设计是带来软件革命的一项已经不算新的技术了,但请不要把稍微动态化一点的程序都冠以AOP的标签,这有助于我们把握技术的前沿方向。所以,在这里由必要向开发界提出元程序逻辑和【AOP本真编程】的概念。我们把应用了【连接点】、【切点】、【通知】以及【方面】的程序设计叫做AOP本真编程或【原生AOP编程】,而以此同元逻辑编程相区别,把AOP本真编程以下的动态化编程称为元逻辑编程。
三、Python、Ruby和Groovy的语言层次分析
对它们三者的语言层次分析有助于我们把握他们的某些实质。很多开发者都有一个共同认识就是:很难在这三者中做出选择主要用何种语言进行24小时的开发。这里我们试图帮助你做出选择。
其实只要我们以面向方面的程序设计作为未来发展方向的话,一切问题就可以迎刃而解。我们在上的表格中看到,Jython没有原生的AOP支持,JRuby倾向于不支持原生AOP编程,Groovy的元对象协议就是AOP的制作。说JRuby倾向于不支持AOP是由于在制作JRuby的过程中,ASM的字节码修改主要是为了Ruby的语法,而不是向Groovy一样使语言本身具有AOP的功能。于是我们可以用下列图示表示Jython和JRuby以及Groovy的层次关系:
从图中我们可以看到,在Java平台之上,Jython和JRuby作为不具备原生AOP功能基本处于同一层次,而Groovy从原生AOP功能上说比Jython和JRuby都强。
四、如何比较经济地使用Python、Ruby和Groovy语言
没有任何一种语言可以彻底地取代另外一种或是所有的语言。因此无论Jython、JRuby和Groovy在AOP的未来功能上如何发展,你都必须对他们进行学习。但是,什么时候该用什么语言进行开发呢?我们来试着总结性回答这个问题。
1、从软件工程的角度上讲,Jython是最节省成本的选择,JRuby次之,而Groovy虽然也很简单但深入一点的开发其实还是较为困难的;
2、从个人学习的角度上讲,可能有很多人处于Rails的原因会偏爱JRuby,也有一些开发者由于Groovy和Java的无缝集成而使用Groovy,然而大家需要知道的是,在这3种语言中其实个人可能会觉得JRuby非常不容易掌握;
3、从团队学习和应用的角度讲,Jython和Groovy是简单的,而JRuby是较为困难的;
4、这3种语言都可以进一步结合Java的字节码处理技术,进一步完成AOP的功能,在这个时候,Jython将碰到的技术问题最多,JRuby次之,而Groovy将碰到的技术问题可能没有。
在Jython、JRuby和Groovy的应用开发上,但愿本文起到抛砖引玉的作用。
【编辑推荐】