前言

面向過程設計和面向?qū)ο笤O計的主要區(qū)別是：是否在業(yè)務邏輯層使用冗長的if else判斷。如果你還在大量使用if else，當然，界面表現(xiàn)層除外，即使你使用java/c#這樣完全面向?qū)ο蟮恼Z言，也只能說明你的思維停留在傳統(tǒng)的面向過程語言上。本文將通過示例代碼給大家介紹關于java編程細節(jié)重構(gòu)之if-else的相關內(nèi)容，下面來一起看看詳細的介紹吧

平時開發(fā)中if-else用的多嗎?

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

但對于優(yōu)秀程序員來說，這并不是好代碼，

為啥?

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

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

那么沒有比 if-else 更合適的語句，比如下面這樣

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

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

在進階高級開發(fā)的路上，應該逐步培養(yǎng)起這種前瞻意識，

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

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

這是完全可能的，以我的經(jīng)驗來說就在不少項目上見過這樣的代碼。

而且代碼執(zhí)行塊中的邏輯可能在幾次迭代后變的非常復雜，就像下面這樣

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

如何重構(gòu)掉這段代碼

對于這種代碼我們重構(gòu)的目標可以有兩個深度，看自己強迫癥的嚴重程度決定

· 繼續(xù)用 if-else，只達到剝離執(zhí)行代碼塊

· 用工廠模式去耦合

對于這兩種其實不是非此即彼的關系，而是優(yōu)化深度不同。第一種相對比較簡單，可以重構(gòu)成下面這樣子

代碼清爽了很多，

現(xiàn)在這段代碼可以清楚的看出來都處理了哪些情況，條件判斷的代碼只關注了條件的不同，

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

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

進一步優(yōu)化

在上面的優(yōu)化之后，如何再用工廠模式來繼續(xù)重構(gòu)呢?

從上的代碼看的出來，不同的條件下，執(zhí)行的邏輯是不同的，那么可以把這種執(zhí)行邏輯抽象出來，用多態(tài)的概念來定義不同的執(zhí)行方式。

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

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

對工廠模式還有印象嗎，上面這段代碼在我之前的工廠模式一文里出現(xiàn)過，這里可以算是工廠模式的一個實際應用。

在經(jīng)過這一輪重構(gòu)之后，我們之前在一個類里面寫的那堆代碼已經(jīng)抽離到多個不同的類里了，

現(xiàn)在在原來的類里的代碼變成怎樣了呢，

重構(gòu)之后各個executor和主類中的耦合已經(jīng)降到很低了，

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

總結(jié)

以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學習或者工作具有一定的參考學習價值，如果有疑問大家可以留言交流，謝謝大家對服務器之家的支持。

原文鏈接：https://juejin.im/post/5b893eaef265da434816006c