參數(Parametric)多型為了規範型態變數的範圍,可對型態變數加上約束,而某些語言取此概念,允許針對某型態定義的函式,可傳入次型態(Subtype)物件。

這種次型態多型是物件導向程式設計中最常見,也是多數開發者所熟悉的多型。次型態關係並非狹義的繼承關係,如果型態S具有型態T所有方法,S可視為T的次型態,次型態多型重點在於,思考物件的行為外觀,讓函式定義可以在不同型態間互通。

類別繼承與介面實作是一種次型態階層
如果S是T的次型態,S型態實例可被當作T型態來使用,這種無需指定額外屬性或進行程式碼修改的取代性,讓函式定義可在不同型態間互通。

以Java為例,當Sprite類別定義了getName與getBlood,SwordsMan與Magician繼承Sprite,若要設計方法使用getName與getBlood顯示角色資訊,以特定(Ad-hoc)多型分別設計show(SwordsMan s)與show(Magician m)並不適當,因為函式實作內容並非特定於SwordsMan或Magician。可設計為show(Sprite s),雖然定義show函式時是針對Sprite型態,但實際執行時,可傳入SwordsMan、Magician或任何繼承Sprite的類別實例,雖然是透過s呼叫getName或getBlood,只要傳入實例繼承Sprite,就具有Sprite定義的所有方法,show函式就可正常執行。

Java中只能繼承一個具體類別,但可以實作多個抽象介面,介面是Java中提供的受限多重繼承,目的之一是提供更有彈性的次型態多型。例如,要設計一個所有東西都會游泳的海洋樂園遊戲,將swim行為外觀定義在Fish類別中並不適合,因為這會使得想具備swim行為外觀的物件都得繼承Fish;如果有個Human類別為了具備swim行為外觀而繼承Fish,顯然非合理設計。(Human會是一種Fish嗎?)

考慮海洋樂園的需求是所有東西都會游泳,而不是所有魚都會游泳,因而有必要將swim的行為外觀抽取出來,定義於Swimmer介面,Fish可以實作Swimmer介面而擁有swim行為外觀,Human也可以實作Swimmer而擁有swim行為外觀,Fish與Human都可視為Swimmer的次型態,但Fish與Human沒有直接繼承關係,因而Human不是一種Fish。

如果今天有個需求是設計doSwim函式,呼叫傳入物件的swim方法,設計doSwim(Swimmer s),顯然會比分別針對Fish及Human設計doSwim(Fish f)及doSwim(Human h)聰明多了,對於doSwim(Swimmer s)來說,雖然定義時是針對Swimmer型態,然而任何實作Swimmer介面的物件必然擁有swim方法,自然就可透過s來參考呼叫。

動態語言具有更廣義的次型態多型

動態語言的變數不需要指定型態資訊,開發者定義函式時不用考慮型態,只要思考變數參考的物件擁有哪些行為外觀。例如設計一個doQuack(duck)函式,當中呼叫duck.quack()方法,即使型態S與型態T彼此沒有繼承關係,但都擁有quack方法,就可將S或T實例傳入doQuack函式中執行。由於duck變數實際上沒有規範型態,所以沒辦法說S是T的次型態,或說T是S的次型態,因而動態語言界稱duck具有鴨子型態(Duck typing)的行為外觀。

靜態語言中宣告型態,主要是為編譯器提供型態資訊,瞭解變數參考的物件有哪些方法可操作;從另一角度來看,型態也是要求編譯器提供約束,確保變數參考的物件實際擁有變數型態所有的方法;動態語言由於變數沒有型態資訊,因而沒有這層約束,然而不變的是,執行時期要求物件必須擁有變數打算操作的所有方法,否則就會執行錯誤,靜態語言只是把這類錯誤儘可能在編譯時期呈現。

型態的意義之一,在於規範物件本身擁有的行為外觀,就doQuack(duck)而言,duck可視為隱含著一種型態(例如鴨子型態),此隱含型態擁有的方法即doQuack中對duck的所有操作,所有傳入doQuack的物件,都必須擁有duck隱含型態上所有方法(具備鴨子型態的行為外觀),傳入doQuack函式的物件型態,都是duck隱含型態的次型態。

Java的介面在語法層面屬於受限多重繼承,但語義層面是將物件的行為外觀具體化型態,實作某個介面代表該物件擁有該介面定義的行為外觀。

以先前海洋樂園的例子來說,Fish與Human實作Swimmer,在語義層面上,表示Fish與Human都擁有Swimmer定義的行為外觀,即使它們沒有直接繼承關係,設計上是將swim的行為外觀從各種物件中抽取出來具體化為Swimmer型態。

思考靜態語言中更廣義的次型態多型
無論如何,靜態語言中必須針對行為外觀定義型態,終究是比動態語言缺少彈性。以Java來說,光是型態名稱就令人煩惱,如果有個Duck類別未實現Swimmer介面,但擁有swim方法,為了要運用doSwim函式,還得修改Duck類別以實作Swimmer介面。

不過靜態語言還是可以透過某些方式,來支援更廣義的次型態多型。以Java為例,可以透過反射(Reflection)機制,不理會物件實際型態,只針對物件上的方法簽署(Signature),實現基於簽署的多型(Signature-Based Polymorphism)。例如實作讓所有具備swim方法的物件都可以執行的doSwim:

void doSwim(Object o) throws Exception {
o.getClass().getMethod("swim", null).invoke(o, null);
}

就行為外觀上,doSwim函式等於捨棄了型態,只在乎物件上是否具備要呼叫的方法簽署,這與動態語言中鴨子型態的概念類似,然而Java以反射機制換取彈性的代價,是付出效能、失去編譯時期檢查,以及複雜的程式邏輯。

同樣身為靜態語言的Scala作得好一些,可以結構型態(Structural typing)保留編譯時期檢查及避免複雜程式邏輯,例如實作讓所有具備swim方法的物件,都可以執行的doSwim:

def doSwim(s: {def swim: Unit}) { s.swim }

捨棄型態而僅思考行為外觀的另一實例,就是物件導向語言導入一級函式特性時的考量。

Java現階段接近一級函式概念的方式,是以匿名內部類別實作含單一抽象方法(Single abstract method)的介面,然而開發者只在意函式參數與本體,此法仍迫使開發者注意介面型態與方法名稱。

JDK8預計引入的Lambda,在語法上捨棄介面型態與方法名稱,例如實作Comparator時可寫為(s1, s2) -> s1.compareTo(s2),然而為了相容既有API及避免創造新的型態系統,Lambda語法的目標型態(Target type)須是函式介面(Functional interface),權宜之計是透過定義通用函式介面,降低API設計者及使用者對記憶型態與方法名稱的負擔。

針對行為外觀思考以取得通用性

次型態多型的本質,在於設計時思考物件間共通的行為外觀,無論該行為外觀在靜態語言中是否具體化為型態,或只是動態語言中由物件單純擁有。實際上在某些程式語言中(像是Ruby),方法與訊息(Message)的概念是分開的,物件被視為訊息的接收者,有能力將訊息對應至要執行的方法,甚至沒有定義方法,也可以處理接收到的訊息。

在這類語言中定義函式時,甚至可僅要求傳入函式的物件,在接收到訊息後,能觸發某些方法或執行對應動作,這樣的函式顯然通用性更大,因為不僅不要求傳入物件的實際型態,連物件是否真正定義了對應方法也不在乎,只要求物件對於傳送的訊息有能力處理,這稱為包容性(Inclusion)多型,實際上,次型態多型是包容式多型的實例之一。

設計時實際思考行為外觀而非型態本身,這與Design by contract,或是Program to an interface, not an implementation等至理名句傳達的概念相同。型態非真正要思考的對象,行為外觀才是重點。

 

作者簡介


Advertisement

更多 iThome相關內容