在學習程式語言的過程中,第一個接觸的流程語法就是if...else,簡單易懂,容易與生活上的經驗做結合,不用多做解釋,因而在遇到需要判斷條件時,就會信手拈來,加以使用,然而,往往在事後檢閱程式碼時,發現到程式碼中充滿了一連串的if...else,而且,無論是形成巢狀、或者是形成瀑布,在視覺、可讀性或者未來除錯上,都會造成一定程度的干擾。

if...else的本質

if...else簡單嗎?如果看過無數次的程式碼中,充滿了無數個if...else,或許就不再覺得簡單了。試著在網路上搜尋「avoid if else」,或者是搜尋「避免 if else」,都能找到數量龐大的文件,有的是尋求,有的是說明如何能不使用if...else。但這是怎麼回事?使用if...else錯了嗎?

程式的本質就是要能根據條件的不同,進行不同的處理,就算是重複執行或者是遞迴,本質上也是需要條件判斷,因而if...else的存在當然是必要的,錯的是我們太熟悉if...else,也因而常漫不經心地使用if...else,而沒能去思考既然名為if...else,實際上它在使用上的本質,就是具有成立與不成立的二元性,如果程式碼中出現了巢狀,或者是瀑布式的if...else排列,若能觀察出條件判斷上重複的二元性到底為何,就會有改用其他設計,避免使用if...else的可能。

在物件導向的世界中,常見的建議之一,就是避免使用if...else來判斷物件的型態,像是在Java中,若是在一連串的if...else中使用了instanceof,根據物件的不同型態進行不同處理的話,九成的情況下,都是不好的訊號,如果這些物件的型態具有繼承關係,稍有經驗的開發者,就會試著使用多型來避免使用if...else。

有時型態的判斷可能是隱性的,例如根據不同的列舉值,進行不同的處理——雖然列舉通常會使用switch來比對,但是,switch本質上等同於使用if/elif...else來對值進行判斷,如果列舉值來源與某個型態有關係,那麼switch的使用可能就是不必要的,在《重構:改善既有程式的設計》中第一章就提到:「在另一個物件的屬性基礎上運用switch,並不是什麼好主意」,這時可以如書中的說明,考慮改用多型設計,從而避免使用switch來進行比對。

運用設計模式

多型是物件導向中的設計元素之一,從多型出發可以導出許多的設計模式,儘管設計模式在今日有時被認為過時,然而在避免if...else這部份來說,設計模式中確實是有幾個可做為思考的方向。

例如,有時if...else會針對某些值來比對,然後決定採取某個策略,像是根據指定的名稱來決定音訊格式的轉換,而未來可能增加音訊格式,這時可考慮Strategy模式的方向。

此時,實際的轉換實作是針對各個策略物件。如果要隱藏策略物件的生成細節的話,可結合Factory method來生成策略物件,至於方法中生成策略物件的方式,若是Java的話,可考慮使用Reflection,或者是使用Map,這時音訊格式的名稱可以為鍵(key),用於取回不同的策略實例。

如果用if...else做了值的比對,在各自做了某些處理後改變狀態,若狀態很多,或者是狀態之間切換方式複雜,那麼可以考慮State模式的方向,讓每個狀態各自成為一個物件,負責自己該狀態時如何進行服務,也知道切換至下一個狀態的方式。

Chain of Responsibility模式,也是一個可以考慮的模式。一個可套用的情境是「如果OOO成立,就XXX」瀑布地重複地出現,這時可以建立不同職責物件,各自負擔「如果OOO成立,就XXX」這樣的職責,然後依需求組織這些職責物件,組織的方式可以是個簡單的清單,然後使用foreach的方式迭代執行,或者是讓每個職責物件知道下一個職責物件會是哪個。

而這就像是個生產線,產品到我面前時,再判斷自己是否該執行工作。

有時對物件型態的判斷可能難以避免,與其寫一堆if...else並結合instanceof之類的分支,不如考慮Visitor模式的做法,將這些分支集中在一個Visitor來管理,運用重載的原理,讓編譯器來協助做型態的判斷,而不是自行撰寫if...else,未來如果需要新增或修改特定的物件實作,也可以集中在Visitor中進行,而不是撰寫更多的if...else分支。

Monad!

現在這個時間點,談到Monad,應該比較不會讓開發者驚悚了吧!隨著函數式典範的元素,逐漸出現在各主流語言之中,開發者或多或少都聽過Monad,或者儘管不瞭解Monad,透過觀察重複的模式,將程式碼流程重構至更高階的設計,也都有了Monad的概念存在,在這些Monad中,有些就包裝了if...else。

如果if...else涉及null值的判斷,且形成巢狀或瀑布式的流程,那麼,可以考慮Optional這樣的Monad,如此一來,除了能避免對空值的認知不同而帶來的問題之外,還可以使用map或flatMap,來解決巢狀或瀑布式的流程(可以參考我先前專欄〈遲到的Optional?〉)。

現在許多語言,多半使用例外處理機制,在函數式語言中,執行結果對或錯,則是傳回一個Either,呼叫者必須比對Either中Right與Left,決定進行哪個動作。在Scala這門語言也有Either,而且更進一步地有著Try這個型態,也可以透過map、flatMap來形成一種鏈狀操作,執行後可能是獲得最後一個操作結果,也可能是鏈狀操作過程中發生錯誤的一個Failure實例(可以參考我先前專欄〈函數式風格錯誤處理〉)。

然而,在Go中,反其而行地,函式有可能發生錯誤時,如果認為是個呼叫者可以處理或必須處理的錯誤,必須傳回error,這類函式通常傳回兩個值(Go允許這麼做),因此Go中常見ok, err = some(param)來拆解傳回值,然後使用if去判斷err是否為nil,決定是否處理錯誤或者進行正常流程,這使得初學者很容易寫出一堆if...else。另一方面,也確實有人試著在Go中實作Monad,來解決這類問題,例如〈maybe.go〉這個Gist

使用if...else要謹慎

使用Monad的概念來處理if...else,是函數式的風格,並非適用於if...else判斷是否有錯誤的全部場合,實際上在Go中,if...return處理錯誤才是慣用法,鼓勵在檢查出錯誤並處理善後之後,直接return(錯誤),進一步的商務流程是撰寫在return之後,而不是else之中,官方文件也隨處可見這樣的寫法,例如〈Effective Go〉中的if說明

避免使用else的原因在於,這可以避免不必要的縮排,而且在if...return之後的程式碼,就必然是沒有任何錯誤的情況下才會執行的邏輯,而不是依賴if中的錯誤處理結果來撰寫後續邏輯,對於可讀性或日後的程式碼除錯來說,都會有幫助。

因此,就算是有瀑布式的if...return在處理錯誤,只要它們實際上是在處理不同的錯誤,在Go中也是合理的作法,當全部的錯誤判斷結束後,真正的商務處理,建議封裝為一個函式來進行呼叫,這形成了Go的特有風格。

因此,重點在於避免隨意地使用if...else,因為,這往往會出現重複的if...else判斷。如果觀察到if...else重複地出現,無論是瀑布式或是巢狀,就要察覺這是一種訊號。如果確實是在做不同的事,最簡單的做法,是將這些不同的事,抽取至不同的函式之中,並取個適當的名稱來突顯意圖。

因此,一旦觀察到有重複的模式出現,則可思考多型、設計模式或者像是Monad等更高階的設計概念,來避免這類惱人的if...else。

作者簡介


Advertisement

更多 iThome相關內容