掃二維碼與項(xiàng)目經(jīng)理溝通
我們?cè)谖⑿派?4小時(shí)期待你的聲音
解答本文疑問/技術(shù)咨詢/運(yùn)營(yíng)咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流
當(dāng)前,對(duì)于Python、Ruby 和Groovy的討論以及學(xué)習(xí)正如火如荼。很多愛好者出于各種目的都在積極地開發(fā)這3種語(yǔ)言的潛力。Python和Ruby也分別有Java的版本:Jython和JRuby,再加上Groovy,把一些軟件初學(xué)者,特別是初初弄軟件架構(gòu)的人員搞得在他們這幾種語(yǔ)言中無(wú)從著手進(jìn)行選擇,本文從面向方面程序設(shè)計(jì)、分析的角度,幫助初學(xué)者對(duì)目前很熱的這3種語(yǔ)言進(jìn)行分類,以期這部分讀者能順利地解決對(duì)這3種語(yǔ)言的認(rèn)識(shí)問題,同時(shí)也解決一些長(zhǎng)期以來(lái)糾纏不清的理論問題。為了達(dá)到這個(gè)目的,我們從以下4個(gè)方面來(lái)進(jìn)行敘述:

創(chuàng)新互聯(lián)建站是網(wǎng)站建設(shè)專家,致力于互聯(lián)網(wǎng)品牌建設(shè)與網(wǎng)絡(luò)營(yíng)銷,專業(yè)領(lǐng)域包括成都網(wǎng)站制作、網(wǎng)站建設(shè)、外貿(mào)網(wǎng)站建設(shè)、電商網(wǎng)站制作開發(fā)、小程序設(shè)計(jì)、微信營(yíng)銷、系統(tǒng)平臺(tái)開發(fā),與其他網(wǎng)站設(shè)計(jì)及系統(tǒng)開發(fā)公司不同,我們的整合解決方案結(jié)合了恒基網(wǎng)絡(luò)品牌建設(shè)經(jīng)驗(yàn)和互聯(lián)網(wǎng)整合營(yíng)銷的理念,并將策略和執(zhí)行緊密結(jié)合,且不斷評(píng)估并優(yōu)化我們的方案,為客戶提供全方位的互聯(lián)網(wǎng)品牌整合方案!
◆Python、Ruby和Groovy都是動(dòng)態(tài)語(yǔ)言
◆元邏輯編程和面向方面的編程
◆Jython、JRuby和Groovy的語(yǔ)言層次分析
◆如何比較經(jīng)濟(jì)地使用Python、Ruby和Groovy語(yǔ)言
一、Python、Ruby和Groovy都是動(dòng)態(tài)語(yǔ)言
【動(dòng)態(tài)語(yǔ)言】是指用該語(yǔ)言編寫的程序在運(yùn)行時(shí)可以動(dòng)態(tài)地改變程序定義的語(yǔ)言要素的層次結(jié)構(gòu)或內(nèi)部結(jié)構(gòu)。比如,你可以在運(yùn)行時(shí)用Ruby的反射機(jī)制或Groovy的元對(duì)象協(xié)議(MOP)完成下列編程:
例1:下面是一個(gè)Ruby腳本
- #Ruby 程序
- #alias_method:用來(lái)記錄被覆蓋的方法
- #define_method:重新定義一個(gè)方法,一般會(huì)調(diào)用alias_method保存的方法
- #class_eval: 根據(jù)傳入字符串的值,給類增加一個(gè)方法。
- 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 "你用過(guò) name 屬性\n"
- }
- println "MOPHandler was asked for property ${property}"
- }
- }
到這里我們必須提出一個(gè)比較嚴(yán)肅的問題:像上面我們看到的兩個(gè)程序一樣,這種反射式的編程和時(shí)下流行的“面向方面”的程序設(shè)計(jì)到底式什么樣的一個(gè)關(guān)系呢?
二、元邏輯編程和面向方面的編程
【元邏輯編程】通常是指利用語(yǔ)言本身的各種固有機(jī)制,特別是一些語(yǔ)言本身的背景機(jī)制進(jìn)行編程的邏輯機(jī)制。比如,反射,又如作用于Java字節(jié)碼的一些開源工程項(xiàng)目(像ASM)等等。當(dāng)你對(duì)Jython、JRuby 和 Groovy 的jar包進(jìn)行分析后,你會(huì)發(fā)現(xiàn)下面的一張表格:
|
語(yǔ)言對(duì)比條目 |
Jython |
JRuby |
Groovy |
|
語(yǔ)言***版本 |
2.2.1 |
1.0.3 |
1.5.1 |
|
基本jar包 |
jython.jar 共計(jì):1177KB |
asm- 2.2.3.jar asm-commons- 2.2.3.jar backport-util-concurrent.jar bsf.jar jline-0.9.91.jar jruby.jar 共計(jì):2932030字節(jié) |
groovy-all- 1.5.1.jar 共計(jì):2718KB |
|
字節(jié)碼處理 |
無(wú) |
有 |
有 |
|
與Java的兼容性 |
稍低 |
中等 |
極高 |
|
元邏輯編程機(jī)制 |
有 |
有 |
有 |
|
開發(fā)者支持程度 |
人數(shù)少 |
人數(shù)中等 |
人數(shù)呈上升趨勢(shì) |
|
掌握難度 |
及其容易 |
不易掌握 |
要懂Java |
|
Web開發(fā)框架慣例 |
無(wú) |
Rails |
Grails |
|
可編譯特性(Java) |
可以 |
可以 |
可以 |
|
原生AOP支持 |
不支持 |
偏向于不支持 |
支持 |
這份簡(jiǎn)單的表格為我們提供了很多有用的信息,在這里我們主要關(guān)注——這3種語(yǔ)言的“元邏輯編程”和“面向方面編程(AOP)”兩項(xiàng)內(nèi)容。
首先我們要清楚元邏輯編程并不是AOP,當(dāng)前很多的開發(fā)者將元邏輯編程和AOP混淆了起來(lái),比如,上面例子1中有些開發(fā)者就將它認(rèn)為是AOP的例子,這里我們來(lái)澄清一下相關(guān)認(rèn)識(shí):
1、AOP本身強(qiáng)調(diào)的是:連接點(diǎn)、切點(diǎn)、通知以及方面,并且AOP很在乎由這些AOP編程機(jī)制帶來(lái)的類層次結(jié)構(gòu)的改變。這一點(diǎn)對(duì)于無(wú)論你用的是靜態(tài)織機(jī)還是動(dòng)態(tài)織機(jī)都一樣。
2、我們不能把類似Java的動(dòng)態(tài)代理機(jī)制就認(rèn)為是AOP的本真編程,比如,例子2中這個(gè)Groovy的程序由一個(gè)子句: new MOPHandler() 就沒有被元對(duì)象協(xié)議捕捉。
因此,我們說(shuō):雖然面向方面的分析與設(shè)計(jì)是帶來(lái)軟件革命的一項(xiàng)已經(jīng)不算新的技術(shù)了,但請(qǐng)不要把稍微動(dòng)態(tài)化一點(diǎn)的程序都冠以AOP的標(biāo)簽,這有助于我們把握技術(shù)的前沿方向。所以,在這里由必要向開發(fā)界提出元程序邏輯和【AOP本真編程】的概念。我們把應(yīng)用了【連接點(diǎn)】、【切點(diǎn)】、【通知】以及【方面】的程序設(shè)計(jì)叫做AOP本真編程或【原生AOP編程】,而以此同元邏輯編程相區(qū)別,把AOP本真編程以下的動(dòng)態(tài)化編程稱為元邏輯編程。
三、Python、Ruby和Groovy的語(yǔ)言層次分析
對(duì)它們?nèi)叩恼Z(yǔ)言層次分析有助于我們把握他們的某些實(shí)質(zhì)。很多開發(fā)者都有一個(gè)共同認(rèn)識(shí)就是:很難在這三者中做出選擇主要用何種語(yǔ)言進(jìn)行24小時(shí)的開發(fā)。這里我們?cè)噲D幫助你做出選擇。
其實(shí)只要我們以面向方面的程序設(shè)計(jì)作為未來(lái)發(fā)展方向的話,一切問題就可以迎刃而解。我們?cè)谏系谋砀裰锌吹?,Jython沒有原生的AOP支持,JRuby傾向于不支持原生AOP編程,Groovy的元對(duì)象協(xié)議就是AOP的制作。說(shuō)JRuby傾向于不支持AOP是由于在制作JRuby的過(guò)程中,ASM的字節(jié)碼修改主要是為了Ruby的語(yǔ)法,而不是向Groovy一樣使語(yǔ)言本身具有AOP的功能。于是我們可以用下列圖示表示Jython和JRuby以及Groovy的層次關(guān)系:
從圖中我們可以看到,在Java平臺(tái)之上,Jython和JRuby作為不具備原生AOP功能基本處于同一層次,而Groovy從原生AOP功能上說(shuō)比Jython和JRuby都強(qiáng)。
四、如何比較經(jīng)濟(jì)地使用Python、Ruby和Groovy語(yǔ)言
沒有任何一種語(yǔ)言可以徹底地取代另外一種或是所有的語(yǔ)言。因此無(wú)論Jython、JRuby和Groovy在AOP的未來(lái)功能上如何發(fā)展,你都必須對(duì)他們進(jìn)行學(xué)習(xí)。但是,什么時(shí)候該用什么語(yǔ)言進(jìn)行開發(fā)呢?我們來(lái)試著總結(jié)性回答這個(gè)問題。
1、從軟件工程的角度上講,Jython是最節(jié)省成本的選擇,JRuby次之,而Groovy雖然也很簡(jiǎn)單但深入一點(diǎn)的開發(fā)其實(shí)還是較為困難的;
2、從個(gè)人學(xué)習(xí)的角度上講,可能有很多人處于Rails的原因會(huì)偏愛JRuby,也有一些開發(fā)者由于Groovy和Java的無(wú)縫集成而使用Groovy,然而大家需要知道的是,在這3種語(yǔ)言中其實(shí)個(gè)人可能會(huì)覺得JRuby非常不容易掌握;
3、從團(tuán)隊(duì)學(xué)習(xí)和應(yīng)用的角度講,Jython和Groovy是簡(jiǎn)單的,而JRuby是較為困難的;
4、這3種語(yǔ)言都可以進(jìn)一步結(jié)合Java的字節(jié)碼處理技術(shù),進(jìn)一步完成AOP的功能,在這個(gè)時(shí)候,Jython將碰到的技術(shù)問題最多,JRuby次之,而Groovy將碰到的技術(shù)問題可能沒有。
在Jython、JRuby和Groovy的應(yīng)用開發(fā)上,但愿本文起到拋磚引玉的作用。
【編輯推薦】

我們?cè)谖⑿派?4小時(shí)期待你的聲音
解答本文疑問/技術(shù)咨詢/運(yùn)營(yíng)咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流