專注於Java領域優質技術號，歡迎關注juejin.im/post/5b893eaef265da434816006c
平時開發中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行，這就是重構的意義。
閱讀更多 Java技術架構 的文章
