Java編程細節-重構-爲何 if-else 不是好代碼

平時開發中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工程師朋友們加入Java架構開發：878249276,羣內提供免費的Java架構學習資料（裏面有高可用、高併發、高性能及分佈式、Jvm性能調優、Spring源碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料）合理利用本身每一分每一秒的時間來學習提高本身，不要再用"沒有時間「來掩飾本身思想上的懶惰！趁年輕，使勁拼，給將來的本身一個交代！