歡迎光臨
每天分享高質量文章

為什麼 if else 不是好代碼?

  • 拋開劑量談毒性都是耍流氓
  • 如何重構掉這段代碼
  • 進一步優化

平時開發中if-else用的多嗎?

其實這是個再正常不過的coding習慣,當我們代碼量小的時候用來做條件判斷是再簡單不過的了。

但對於優秀程式員來說,這並不是好代碼,

為啥?

拋開劑量談毒性都是耍流氓

在使用條件判斷陳述句的地方,如果代碼量小,需要判斷的場景少的話,

那麼沒有比 if-else 更合適的陳述句,比如下麵這樣

if(object.getIndex() > 0) {
    //do something
else {
    //do other things
}

那在什麼情況下 if-else 才會變差呢?

以上面的代碼為例子,當需要判斷的情況逐漸增加的時候,上面的代碼可能會變的難以維護。

在進階高級開發的路上,應該逐步培養起這種前瞻意識,

即使在代碼還在起步階段,應該要能夠看到將來代碼發展的趨勢,

比如上面的代碼,當情況越來越多的時候,if-else可能會發展出許多個分支:

img

這是完全可能的,以我的經驗來說就在不少專案上見過這樣的代碼。

而且代碼執行塊中的邏輯可能在幾次迭代後變的非常複雜,就像下麵這樣

img

看到這段代碼第一感覺就是想殺個小伙伴祭天。

如何重構掉這段代碼

對於這種代碼我們重構的標的可以有兩個深度,看自己強迫症的嚴重程度決定

· 繼續用 if-else,只達到剝離執行代碼塊

· 用工廠樣式去耦合

對於這兩種其實不是非此即彼的關係,而是優化深度不同。第一種相對比較簡單,可以重構成下麵這樣子

img

代碼清爽了很多,

現在這段代碼可以清楚的看出來都處理了哪些情況,條件判斷的代碼只關註了條件的不同,

而對於不同條件的具體處理邏輯我們剝離到了其他地方,

這樣即使寫到腦袋迷糊,也不至於說漏了哪個條件沒判斷。

進一步優化

在上面的優化之後,如何再用工廠樣式來繼續重構呢?

從上的代碼看的出來,不同的條件下,執行的邏輯是不同的,那麼可以把這種執行邏輯抽象出來,用多型的概念來定義不同的執行方式。

img

完成了這一步之後,就可以把代碼塊中不同條件下的方法抽到各個不同的具體類裡面去了,

img

還可以進一步優化嗎?可以的,甚至這裡的條件判斷都可以不要,我們可以定義一個工廠來把 new ExecutorWithTag()這件事給包了,

img

對工廠樣式還有印象嗎,上面這段代碼在我之前的工廠樣式一文里出現過,這裡可以算是工廠樣式的一個實際應用。

在經過這一輪重構之後,我們之前在一個類裡面寫的那堆代碼已經抽離到多個不同的類里了,

現在在原來的類里的代碼變成怎樣了呢,

img

重構之後各個Executor和主類中的耦合已經降到很低了,

而且代碼整潔度提高了很多,之前那個類的一段50+行的代碼變成了2行,這就是重構的意義。

赞(0)

分享創造快樂