1. 介紹

本篇內(nèi)容開始介紹Groovy中的各種類型知識(shí)。將會(huì)分多篇文章詳細(xì)介紹和學(xué)習(xí)Groovy中的有關(guān)于類型的相關(guān)知識(shí)點(diǎn)。

內(nèi)容來(lái)源于Groovy官方文檔中得到1.6.6. Typing中的相關(guān)知識(shí)點(diǎn)。

內(nèi)容比較多。可以通過(guò)目錄查詢想了解的模塊。

2. 可選類型-Optional typing

可選類型是指即使不在變量上設(shè)置顯式類型，程序也可以工作。作為一種動(dòng)態(tài)語(yǔ)言，Groovy自然實(shí)現(xiàn)了這一特性，例如，當(dāng)聲明一個(gè)變量時(shí)：

String aString = 'zinyan.com'   //聲明了一個(gè)變量字符串                    
//我們調(diào)用這個(gè)字符串的大小寫轉(zhuǎn)換方法并輸出
println aString.toUpperCase()   //輸出：ZINYAN.COM

在Groovy中，我們可以通過(guò)可選類型關(guān)鍵字：def 來(lái)代替：

def aString = 'zinyan.com'   //聲明了一個(gè)變量字符串                    

println aString.toUpperCase()

兩種寫法是一樣的。def不只是可以代替String，它可以代替任何的一種數(shù)據(jù)類型。

所以在這里使用顯式類型并不重要。當(dāng)我們將此功能與靜態(tài)類型檢查相結(jié)合時(shí)，這尤其有趣，因?yàn)轭愋蜋z查器執(zhí)行類型推斷。

同樣，Groovy不強(qiáng)制在方法中聲明參數(shù)的類型：

String concat(String a, String b) {
a+b
}
println concat('zinyan','.com') //輸出：zinyan.com

可以使用def作為返回類型和參數(shù)類型來(lái)重寫，以便利用duck類型，如以下示例所示：

def concat(def a, def b) {                              
a+b
}
println concat('zinyan','.com') //輸出：zinyan.com      
println concat(1,2) //輸出：3

我們通過(guò)def可選類型，就能實(shí)現(xiàn)動(dòng)態(tài)的參數(shù)處理了。擴(kuò)展了方法的使用范圍。

建議在這里使用def?關(guān)鍵字來(lái)描述一個(gè)方法的意圖，該方法應(yīng)該適用于任何類型，但從技術(shù)上講，我們可以使用Object?，結(jié)果是一樣的：在Groovy中，def?嚴(yán)格等同于使用Object。

最終，可以從返回類型和描述符中完全刪除該類型。但如果要從返回類型中刪除它，則需要為該方法添加顯式修飾符，以便編譯器可以在方法聲明和方法調(diào)用之間產(chǎn)生差異，如以下示例所示：

private concat(a,b) {                                  
a+b
}
println concat('zinyan','.com') //輸出：zinyan.com      
println concat(1,2) //輸出：3

我們直接將def給省略了。

在公共API的方法參數(shù)或方法返回類型中，省略類型通常被認(rèn)為是一種不好的做法。雖然在局部變量中使用def?并不是一個(gè)真正的問(wèn)題，因?yàn)樽兞康目梢娦詢H限于方法本身，但在方法參數(shù)上設(shè)置def?時(shí)，def將在方法簽名中轉(zhuǎn)換為Object，這使得用戶很難知道哪種類型的參數(shù)是期望的類型。

PS：總結(jié)來(lái)說(shuō)，我們可以將類型定義為def，然后還能將def給省略掉。但是不建議大家在對(duì)外提供的api中省略def。容易造成閱讀困難。

其次，def就是java中的Object對(duì)象。只是中間的各種轉(zhuǎn)換解析等功能Groovy在編譯器中幫我們進(jìn)行了轉(zhuǎn)換。

3. 靜態(tài)類型檢測(cè)-Static type checking

默認(rèn)情況下，Groovy在編譯時(shí)執(zhí)行最小的類型檢查。由于它主要是一種動(dòng)態(tài)語(yǔ)言，所以靜態(tài)編譯器通常無(wú)法在編譯時(shí)進(jìn)行的大多數(shù)檢查。通過(guò)運(yùn)行時(shí)元編程添加的方法可能會(huì)改變類或?qū)ο蟮倪\(yùn)行時(shí)行為。

通過(guò)示例介紹一下：

//創(chuàng)建一個(gè)對(duì)象
class Person {                                                          
String firstName
String lastName
}
//初始化該實(shí)例對(duì)象
def p = new Person(firstName: 'Zin', lastName: 'yan')  
println p.formattedName

在動(dòng)態(tài)語(yǔ)言中，像上述示例這樣的代碼不拋出任何錯(cuò)誤是很常見的。在Java中，這通常會(huì)在編譯時(shí)失敗。

我們直接執(zhí)行上面的代碼就會(huì)輸出：

Caught: groovy.lang.MissingPropertyException: No such property: formattedName for class: Person
groovy.lang.MissingPropertyException: No such property: formattedName for class: Person
at zinyan.run(zinyan.groovy:8)

錯(cuò)誤提示，我們?nèi)绻胝＿\(yùn)行，就需要執(zhí)行依賴運(yùn)行時(shí)元編程。也就是說(shuō)修改運(yùn)行時(shí)狀態(tài)，執(zhí)行動(dòng)態(tài)特性：

Person.metaClass.getFormattedName = { "$delegate.firstName $delegate.lastName" }

完整示例為：

//創(chuàng)建一個(gè)對(duì)象
class Person {                                                          
    String firstName
    String lastName
}
//初始化該實(shí)例對(duì)象
Person.metaClass.getFormattedName = { "$delegate.firstName $delegate.lastName" }
def p = new Person(firstName: 'Zin', lastName: 'yan')  
println p.formattedName

這意味著，一般來(lái)說(shuō)，在Groovy中，除了聲明類型之外，我們不能對(duì)對(duì)象的類型做出任何假設(shè)，即使我們知道它，也無(wú)法在編譯時(shí)確定將調(diào)用什么方法，或者將檢索哪個(gè)屬性。這個(gè)特性用在DSL和測(cè)試腳本編寫中有不少的特性。這里就不展開了。

然而，如果我們的程序不依賴動(dòng)態(tài)特性，并且來(lái)自靜態(tài)世界（特別是來(lái)自Java思維），那么在編譯時(shí)沒(méi)有捕捉到這樣的“錯(cuò)誤”可能會(huì)出現(xiàn)崩潰。正如我們?cè)谇懊娴氖纠锌吹降模幾g器不能確定這是一個(gè)錯(cuò)誤。為了讓編譯器意識(shí)到這一點(diǎn)，必須明確指示編譯器我們正在切換到類型檢查模式。這可以通過(guò)使用

@groovy.transform.TypeChecked注釋類或方法來(lái)完成。

當(dāng)激活類型檢查時(shí)，編譯器將新增以下的工作:

類型推斷被激活，這意味著即使對(duì)局部變量使用def，類型檢查器也能夠從賦值中推斷出變量的類型.

方法調(diào)用在編譯時(shí)解析，這意味著如果沒(méi)有在類上聲明方法，編譯器將拋出錯(cuò)誤

通常，在靜態(tài)語(yǔ)言中查找的所有編譯時(shí)錯(cuò)誤都會(huì)出現(xiàn)：方法未找到、屬性未找到、方法調(diào)用的不兼容類型、數(shù)字精度錯(cuò)誤等…

下面讓我們描述類型檢查器在各種情況下的行為，并解釋在代碼中使用@TypeChecked的限制。

3.1 @TypeChecked注解

在編譯時(shí)激活類型檢查。

我們可以將@groovy.transform.TypeChecked注解添加到類的開頭，

讓編譯器編譯該類時(shí)啟用類型檢測(cè)：

@groovy.transform.TypeChecked
class Calculator {
    int sum(int x, int y) { x+y }
}

或添加到方法中：

class Calculator {
    @groovy.transform.TypeChecked
    int sum(int x, int y) { x+y }
}

在第一種情況下，所有方法、屬性、字段、內(nèi)部類… 注釋類的類型將被檢查，而在第二種情況下，只有方法和它包含的潛在閉包或匿名內(nèi)部類將被類型檢查。

我們同時(shí)也可以通過(guò)@TypeChecked(TypeCheckingMode.skip）對(duì)其進(jìn)行注釋來(lái)指示類型檢查器跳過(guò)類型檢測(cè)：

import groovy.transform.TypeChecked
import groovy.transform.TypeCheckingMode
//對(duì)GreetingService類的所有方法和類進(jìn)行類型檢測(cè)。
@TypeChecked                                        
class GreetingService {
    String greeting() {                             
        doGreet()
    }
    //對(duì)doGreet方法跳過(guò)類型檢測(cè)。
    @TypeChecked(TypeCheckingMode.SKIP)             
    private String doGreet() {
        def b = new SentenceBuilder()
        b.Hello.my.name.is.Zinyan                     
        b
    }
}
def s = new GreetingService()
assert s.greeting() == 'Hello my name is Zinyan'

在前面的示例中，SentenceBuilder?依賴于動(dòng)態(tài)代碼。沒(méi)有真正的Hello?方法或?qū)傩裕虼祟愋蜋z查器通常會(huì)發(fā)出異常，編譯將失敗。因?yàn)槭褂蒙善鞯姆椒ū粯?biāo)記為TypeCheckingMode.SKIP，此方法跳過(guò)了類型檢查，因此即使類的其余部分進(jìn)行了類型檢查也會(huì)編譯代碼。

以下部分描述Groovy中類型檢查的語(yǔ)義。

3.2 類型檢查分配

類型A?的對(duì)象o?可以賦值給類型T的變量當(dāng)且僅當(dāng):

• T? 等于A。
• 或者T? 是以下幾種類型之一：String?, boolean?, Boolean? 或Class。
• 或者o? 是空的，T不是一個(gè)基本類型。
• 或者T和A? 是一個(gè)數(shù)組， A? 的組件類型可分配給 T 的組件類型。
• 或者T? 是一個(gè)數(shù)組，A? 是一個(gè)集合或流（stream ）， A?的組件類型可分配給 T的組件類型。
• 或者T? 是 A 的超類。
• 或者T?是由 A 實(shí)現(xiàn)的接口。
• 或者T?或 A 是基本類型，它們的封裝類型是可賦值的。
• 或者T?extedns groovy.lang.Closure?是一個(gè)閉包，同時(shí)A 是SAM類型(單一抽象方法類型)。
• 或者T和A?源自java.lang. Number，并遵循下表：

3.3 List 和Map 的構(gòu)造函數(shù)

除了上面的賦值規(guī)則，如果賦值被認(rèn)為是無(wú)效的，在類型檢查模式下，如果滿足以下條件，List或Map A?可以賦值給類型T的變量:

賦值是一個(gè)變量聲明，A?是一個(gè)List，T有一個(gè)構(gòu)造函數(shù)，其參數(shù)與List的元素類型匹配。

賦值是一個(gè)變量聲明，A是一個(gè)map，T有一個(gè)無(wú)參數(shù)構(gòu)造函數(shù)，每個(gè)map鍵都有一個(gè)屬性。

具體示例如下：

@groovy.transform.TupleConstructor
class Person {
    String firstName
    String lastName
}
Person classic = new Person('Zin','yan')

可以使用“列表構(gòu)造函數(shù)”:

Person list = ['Zin','yan']

創(chuàng)建一個(gè)Person對(duì)象出來(lái)，也可以使用Map構(gòu)造函數(shù)創(chuàng)建一個(gè)Person對(duì)象:

Person map = [firstName:'Zin', lastName:'yan']

如果使用Map構(gòu)造函數(shù)，則會(huì)對(duì)映射的鍵進(jìn)行額外檢查，以檢查是否定義了同名的屬性。例如，以下代碼將在編譯時(shí)失敗:

@groovy.transform.TupleConstructor
class Person {
    String firstName
    String lastName
}
Person map = [firstName:'Zin', lastName:'yan', age: 1024]

就會(huì)觸發(fā)以下錯(cuò)誤：

org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast object '{firstName=Zin, lastName=yan, age=1024}' with class 'java.util.LinkedHashMap' to class 'Person' due to: org.codehaus.groovy.runtime.metaclass.MissingPropertyExceptionNoStack: No such property: age for class: Person

3.4 方法解析

在類型檢查模式下，方法在編譯時(shí)解析。解析通過(guò)名稱和參數(shù)工作。返回類型與方法選擇無(wú)關(guān)。參數(shù)類型與以下規(guī)則中的參數(shù)類型匹配：

類型A?的參數(shù)o?可以用于類型T的參數(shù)，當(dāng)且僅當(dāng)：

• T? 等于A。
• 或者T?是一個(gè)String，A?是一個(gè)GString。
• 或者o?為空，T不是基礎(chǔ)類型。
• 或者T?是一個(gè)數(shù)組，A?是一個(gè)數(shù)組，A?的組件類型可以分配給T的組件類型。
• 或者T是A的超類。
• 或者T是A實(shí)現(xiàn)的接口。
• 或者T或A是基本類型，它們的封裝類型是可賦值的。
• 或T?擴(kuò)展了groovy.lang.Closure?，而A是SAM類型(單一抽象方法類型)。
• 或者T和A?派生自java.lang.Number，并遵循與數(shù)字賦值相同的規(guī)則。

如果在編譯時(shí)沒(méi)有找到具有適當(dāng)名稱和參數(shù)的方法，則拋出錯(cuò)誤。下面的例子說(shuō)明了與“正?！盙roovy的區(qū)別:

class MyService {
    void doSomething() {
        printLine 'Do something'            
    }
}

printLine是一個(gè)錯(cuò)誤，但由于我們處于動(dòng)態(tài)模式，錯(cuò)誤在編譯時(shí)不會(huì)被捕獲

上面的例子展示了一個(gè)Groovy能夠編譯的類。但是，如果嘗試創(chuàng)建MyService?的實(shí)例并調(diào)用doSomething?方法，那么它將在運(yùn)行時(shí)失敗，因?yàn)閜rintLine?不存在。當(dāng)然，我們已經(jīng)展示了Groovy如何使它成為一個(gè)完全有效的調(diào)用，例如通過(guò)捕獲MethodMissingException?或?qū)崿F(xiàn)一個(gè)自定義元類，但如果你知道你不是在這種情況下，@typecheck會(huì)派上用場(chǎng):

@groovy.transform.TypeChecked
class MyService {
    void doSomething() {
        printLine 'Do something'            
    }
}

僅僅添加@typecheck?就會(huì)觸發(fā)編譯時(shí)方法解析。類型檢查器將嘗試在MyService?類上找到一個(gè)接受String的方法printLine，如果找不到。它將編譯失敗，并顯示以下消息:

Cannot find matching method MyService#printLine(java.lang.String)

理解類型檢查器背后的邏輯很重要:它是一種編譯時(shí)檢查，因此根據(jù)定義，類型檢查器不知道我們所做的任何類型的運(yùn)行時(shí)元編程。這意味著如果激活類型檢查，沒(méi)有@TypeChecked也完全有效的代碼將不再編譯。如果你想到duck typing，這一點(diǎn)尤其重要:

class Duck {
    void quack() {              
        println 'Quack!'
    }
}
class QuackingBird {
    void quack() {              
        println 'Quack!'
    }
}
@groovy.transform.TypeChecked
void accept(quacker) {
    quacker.quack()             
}
accept(new Duck())

比如引入一個(gè)接口，但基本上，通過(guò)激活類型檢查，獲得了類型安全，但失去了語(yǔ)言的一些特性。希望Groovy能引入一些特性，比如流類型，以縮小類型檢查和非類型檢查Groovy之間的差距。

4. 小結(jié)

本篇內(nèi)容未完待續(xù)?？梢酝ㄟ^(guò)下一篇了解完整內(nèi)容。

以上內(nèi)容參考Groovy 官方文檔：http://docs.groovy-lang.org/docs/groovy-4.0.6/html/documentation/#_typing