Java編程細節重構之if-else不是好代碼的原因分析

小編給大家分享一下Java編程細節重構之if-else不是好代碼的原因分析，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

前言

面向過程設計和面向對象設計的主要區別是：是否在業務邏輯層使用冗長的if else判斷。如果你還在大量使用if else，當然，界面表現層除外，即使你使用Java/C#這樣完全面向對象的語言，也只能說明你的思維停留在傳統的面向過程語言上。

平時開發中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編程細節重構之if-else不是好代碼的原因分析”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！