由於變數本身不帶型態資訊,動態定型語言在設計方法時,想要不受限於物件型態而僅思考物件應當具有的行為,也就是進行所謂Duck typing時,極為容易。

然而Duck typing並非動態定型語言專屬,靜態定型語言也能夠進行Duck typing,只不過在方式上通常較動態定型麻煩,既然動態與靜態定型都有能力進行Duck typing,那麼進一步思考兩者間的差異,才能真正發揮與掌握Duck typing。

你只要像個鴨子呱呱叫

支持者最愛擁抱動態定型語言的理由之一就是,實作Duck typing時極為容易,也就是「當我看到一隻鳥,它走路像鴨子,游泳像鴨子,叫聲像鴨子,我就稱其為鴨子」此說法最初起源,可能來自美國印第安納詩人James Whitcomb Riley,用來表示可觀察未知事物的外在特徵,以推斷該事物的本質,後來在程式設計也常用來隱喻動態定型語言的設計風格,若使用動態定型的Ruby語言來示範,可定義一個doQuack方法:

def doQuack(duck)
    duck.quack
end

參數duck沒有任何型態宣告,也因此,不會有任何型態約束,只要傳進來的物件具有quack方法就可以了,在快速開發、程式規範尚未確立的階段若有新需求,只要在doQuack方法中修改,不用費心地修改類別等定義,這個特性是非常有用的功能,如果語言本身又有支持物件個體化(Object individuation),即使物件原本沒有quack方法,也可以臨時添加再做為引數傳入。例如,Ruby可以臨時為物件定義單例方法(singleton method ),就能滿足呼叫doQuack的需求:

dog = Dog.new
def dog.quack
    print "quack"
end
doQuack(dog)

靜態定型語言也能Duck typing

常見對靜態定型語言的誤解是,它們沒辦法進行Duck typing,實際上並非如此,身為靜態定型的Scala,可以藉由Structural typing語法,在參數上宣告傳入的物件必須具備何種行為,例如,def doQuack(duck: {def quack: Unit}),如此,任何具有quack行為的物件,都能呼叫doQuack方法,而不具quack行為的物件試圖傳入,就會引發編譯錯誤,也就是又多了個編譯時期檢查的優點。

也因為這樣,而有人說:Scala的Structual typing只能算是靜態時期的Duck typing,動態定型語言的Duck typing實際上發生於執行時期,這多了更多彈性,然而,在Java這門靜態定型語言中,透過反射(Reflection)機制,也能實作出具備動態時期Duck typing的功能,不過,這不是Java語法上的直接支援,而是透過程式庫來達成,因而就實作本身來說,程式碼囉嗦了許多。

靜態定型語言本身就對型態多所約束,像Java在實作Duck typing時較為囉嗦,多半也表示了這門語言,不太希望你使用Duck typing,Scala雖稍微放寬了限制,提供了Structural typing語法,不過仍要求你符合型態約束,{def quack: Unit}實際上就是在定義一個匿名的型態,這個型態下規範了呼叫函式時,物件本身應當具備哪些行為子集。

Duck typing是在思考一組行為集合

實際上,在動態定型語言中使用Duck typing時,也是在使用一組行為集合,也就是你在方法中對該物件進行的操作集合,傳入的物件會有許多行為,但如果行為中沒有方法要求的子集合,就會引發執行時期錯誤,Scala的Structural typing語法,其實是在協助將這種執行時期錯誤,推向至編譯時期就檢查出來,若是使用Java的反射機制,不希望引發執行時期錯誤,就得在執行時期進行檢查,確認物件是否有要求的行為子集。

Alex Martelli在2000年於comp.lang.python新聞群組就用了Duck typing這名詞,他談到:「別檢查它是不是一隻鴨子,要檢查它是不是像隻鴨子呱呱叫,像隻鴨子走路等,取決於你需要哪些鴨子似的行為來操弄語言」,以先前Ruby版本的doQack方法為例,你採用了Duck typing,若需要對傳入物件進行檢查時,不是使用is_a?方法來檢查傳入物件是否為Duck型態的實例,而要使用respond_to?來檢查是否具有quack行為,畢竟你採用了Duck typing,檢查時也要Duck typing,在JavaScript領域常見對物件進行特性偵測的技巧,也是同理。

Duck typing是在思考一組行為集合,有時也要再思考一下,這組行為應當屬於誰?是否該屬於某一個類別的實例?舉例來說,如果你為了滿足doQuack方法,曾多次在程式中如先前對某類別實例臨時添加方法後傳入,實際上Ruby中對實例定義單例方法,就開啟了該實例的匿名單例類別(Anonymous singleton class),也就是你還是在屬於該實例的類別上定義了方法,只是該類別是匿名的,如果你經常做這個動作,就該想想是不是要使用開放類別(Open class)語法,或者是直接將quack方法定義在產生該實例的類別之上。

如果Duck typing的這組行為,是可以由不同類別的實例來共享,那麼應該思考一下,這組行為是不是可以抽出為模組(module)重用,並在需要的類別定義中包括(include)該模組,實際上,在JDK8之後interface有了預設方法(Default method),就是在解決這類需求,即使在JDK8之前,interface只能定義公開的行為規範,其目的也是在要求開發者思考,哪些行為集合需要共用,而這組行為該取個明確名稱,並要求開發者共同遵守與實作。

你真的想要狗呱呱叫嗎?

在Java這門靜態定型語言中,有著許多的強制性,令Java顯得囉嗦,然而在某些場合,囉嗦反而是優點,如果某組行為應當屬於某個類別,而方法的參數宣告為該類別,那麼不是該類別的實例,就不能傳入方法,也許你並不是真的想要一隻狗傳入doQuack方法。而在動態定型語言中,設計API的開發者也許知道不該傳入一隻狗給doQuack,然後API(特別是公用API)客戶端不見得知道或願意遵守這種慣例,若是如此,檢查Duck typing的行為就是必要的。

也許你真的想要一隻狗呱呱叫,也可以允許一隻貓喵喵叫,但就是不允許一隻龍呱呱叫,像這類情況,Java中可以定義DuckLike介面,讓狗與貓的類別來實作DuckLike介面,這樣只要在doQuack方法上宣告DuckLike,只要龍沒有實作DuckLike介面,編譯器就會在執行前抱怨有隻龍不想遵守規範,在開發成員眾多、水準不一、慣例之類的約束難以貫徹或確實傳達的環境中,這種強制規範算是種好處。

無論是靜態定型、動態定型或是Duck typing,都得進行定型,也就是有哪些相關的值或行為能夠集合在一起、成為一個型態,無論那型態是否具有名稱,因為,沒有了型態宣告,沒有了編譯器在程式執行前的型態約束檢查,並不代表你不會遇到定型的問題,只不過是將問題推到執行時期罷了。在具有更大彈性的動態定型或動態語言中,你擁有更多的選擇性,而不是被編譯器之類的工具直接限制住,就因為擁有更多選擇,對於任何像Duck typing這類具強大威力的特性,都得進一步思考,才能瞭解這些強大威力的特性背後代表的設計意義。

作者簡介


Advertisement

更多 iThome相關內容