物件導向與函數式並不衝突,兩者可相輔相成。當面對職責混亂的物件,可試著以函數式概念對物件的函式進行重構,若一開始不知如何畫分物件職責,可試著先以函式為單元進行設計,再看看函式是否可進一步重構出子函式。

當問題被分解為子問題,函式被切得夠細小,回過頭來會發現數個函式間的關聯性,這時無論是使用類別組織資料、將函式搬運至適當類別之中,都會有較清楚的判斷界線,從而實現更高階的物件導向概念。

邏輯泥塊是畫分物件職責的阻礙
在《重構──改善既有程式的設計》書中第一章的影片出租店案例中,初看Movie、Customer與Rental類別的職責都十分簡單,然而Customer的statement函式過於冗長,這表示statement做的事情實在太多了,由於充斥了邏輯泥塊,看不出Movie與Rental可以如何分擔Customer的職責。

當一個類別的方法內容過於冗長,充滿了邏輯泥塊的時候,幾乎可以斷定,擁有該函式的類別擔負了過多的職責。

分解邏輯泥塊是畫分職責前必要的動作,當單一任務的函式從邏輯泥塊中分解出來,才能清楚觀察出哪個物件,促成了此任務的完成,進一步地更能為函式取個適當的名稱。

舉例來說,當《重構》書中「金額計算」的職責從statement分解出來成為amountFor函式,就可以清楚看出amountFor僅使用了Rental物件來完成任務,而沒有用到任何Customer物件的資訊,amountFor函式顯然應該從Customer搬移至Rental類別中。在搬運到Rental之後,amountFor這個名稱沒有意義,因為職責改用Rental物件主動完成,將amountFor改為getCharge會是適當的選擇。

如果因為函式中充滿邏輯泥塊,導致物件間職責畫分困難,往往代表著類別間的耦合程度就高。

當《重構》書中「金額計算」的職責從statement分解出來,並搬移至Rental類別之後,就減少了statement中對Movie的多處引用,如果再將「常客積點計算」的職責,從statement分離至Rental,並進一步將statement中的each.getMovie().getTitle(),改為each.getMovieTitle(),那麼Customer與Movie耦點,就會被Rental完全切開。

一旦物件的職責畫分清楚,耦合度低,物件間的相對而言不易變動的公開協定,就容易形成,此時想獨立重構某個物件或模組,就不易彼此牽動。

就如同《重構》書中,對statement作了重構之後,才有辦法對Movie類別再進行重構,分離出Price類別,並進一步以多型取代條件判斷分支。如果不分解邏輯泥塊,不將冗長函式重構為子函式,不將問題畫分為子問題,這一切都不可能發生。

非物件導向語言的物件導向概念

關於分解邏輯泥塊,可借鏡函數式概念來啟發,前篇〈用函數式重構程式碼與演算法〉談過。

有些語言是多重典範,同時提供支援物件導向與函數式的元素,以函數式分解問題,並進一步畫分物件職責,就是很自然的過程。

實際上在不支援物件導向的語言,甚至是純函數式語言中,即便語法不同,但架構上亦常有物件導向的概念。將函式重構為夠細小的函式,接著利用語言元素適當組織,最後形成物件導向概念的架構,此過程與《重構》書中案例其實十分類似。

就成品而言,實際上,有些非物件導向語言構築而成的程式庫,就有著物件導向的組織架構。

以C語言開發的GTK為例,雖然C語言沒有類別,但以struct來組織相關聯的資料,事實上GTK也不拘泥名稱,直接稱由struct定義的資料為類別,在函式組織上則以名稱來辨別相關職責。

以GtkWindow相關的函式為例,gtk_window_new用來封裝建立struct的細節,gtk_window_set_title用來設定標題名稱等;GTK在struct上使用鏈結(link),使得GtkWindow與GtkWidget等之間具有繼承概念,而許多gtk_window_開頭的函式,首個參數都接受GtkWidget指標,看來就像是GtkWindow專用的函式,這與物件導向中,將函式直接組織在類別中,概念其實是相同的。

即便是純函數式的Haskell而言,亦有元素可以展現物件導向精神。data關鍵字用以定義新型態,型態類(Typeclass)用來描述附屬於某型態類的型態應該實現的行為,而型態變數(Type variable)用來讓函式展現多型行為。

在運用這些高階語法之前,必須以一組運作良好的函式作為基礎。由於Haskell是純函數式語言,分解問題是必然的出發點,因此很容易發覺應用data關鍵字、型態類與型態變數的時機,再搭配模組(module)適當開放可匯入(import)的函式,亦可達到封裝相關函式,隱藏內部實現機制之作用。

直接從函式出發再來辨識物件

既有程式碼中的邏輯泥塊,既然是畫分職責的阻礙,將之分解就可促進職責畫分,而後獲得更高階或更抽象的物件導向架構;既然非物件導向語言亦可形成物件導向的概念,那麼對於同時具有函式及物件導向元素的語言來說,若初步無法釐清物件應有職責時,直接從函式出發解決問題,而後對函式進行重構,將問題逐步分解,這個過程就不只為了獲得啟發,而是實際可進行的物件導向設計步驟。

直接從函式出發可以有兩個方向,一是先快速而隨興(Quick and dirty)將問題解決,而後分解函式中的邏輯泥塊,使之成為細小函式;另一個方向是直接分解問題,先用子函式解決子問題,而後組織子函式來解決整個問題。

無論是哪個方向,最後可能會發現數個函式都使用了同一組參數,此時可將這組參數組合為選項物件(Option object),接著用該物件對數個函式重構,審視重構後的函式,是否需修改為適當名稱。

如果呼叫相關函式時,每次都要先進行選項物件的產生或初始化過程,這個過程可分解為初始函式;對於每次要取得物件字串描述的流程,可以分解而得到一個toString之類的函式……,當所有函式重構完成之後,對於具有相同選項物件作為參數的函式,可以開始使用類別將之組織,選項物件上的特性(Property)就成了物件內部狀態,初始函式就成為建構式,函式上原本的選項物件參數,也許不再需要或使用this或self取代,函式中對選項物件的參考成為直接取用物件內部狀態。

當一切就緒,你也許會發現有些函式獨立存在,這或許就是公用函式(Utility function)的候選者。

職責清晰的最小單元是高階抽象基礎
無論是重構中的分解邏輯泥塊或是函數式地強制分解問題,都是為了獲得職責清晰的最小單元,才能進一步進行高階的抽象化。

即便是在物件導向為主要典範的語言中,組織職責的最小單位通常就是函式,類別只是用來組織相關資料及函式時的進一步抽象。如果函式的職責混亂,基於這種函式而建立的物件,其職責必然混亂,而整個程式也是毫無架構可言。

就物件導向而言,只有職責清晰且單一的函式,才有辦法加以分類,因而有了類別封裝,有了類別才有辨法進一步談及繼承,實際上繼承是一種抽象化過程,將多個類別共用的程式碼基礎分解出來,以便進一步架構更複雜的多型行為。

如果說遞迴是分解迴圈泥塊後的外在表現,那麼,多型可說是分解多重條件判斷分支泥塊的抽象成果,這也是一種職責分解的過程,亦即將每個分支進行的工作分解至各個子類別中。一旦有了封裝、繼承、多型,更高度的抽象設計,如模式、架構等也才能因應而生。

 

作者簡介


Advertisement

更多 iThome相關內容