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

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

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

為啥？

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

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

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

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

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

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

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

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

比如上面的程式碼，當情況越來越多的時候，if-else可能會發展出許多個分支：

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

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

看到這段程式碼第一感覺就是想殺個小夥伴祭天。

如何重構掉這段程式碼

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

· 繼續用 if-else，只達到剝離執行程式碼塊

· 用工廠樣式去耦合

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

程式碼清爽了很多，

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

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

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

在上面的最佳化之後，如何再用工廠樣式來繼續重構呢？

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

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

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

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

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

現在在原來的類裡的程式碼變成怎樣了呢，

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

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