CTO：再寫if-else，逮著罰款1000！
來自公眾號：51CTO技術棧
作者：Nicklas Millard，在丹麥的四大咨詢公司之一中擔任高級技術顧問，主要擔任客戶項目的首席開發(fā)人員和解決方案架構師。
編輯：陶家龍
出處：https://medium.com/swlh/5-ways-to-replace-if-else-statements-857c0ff19357
本文并不肯定或者否定哪一種寫法，僅僅為大家提供一些其他的編碼思路或者一些值得借鑒的點子。
設計更好的軟件，替換 If-Else 的 5 種方法，從入門到高級示例
If-Else 通常是一個糟糕的選擇，它導致設計復雜，代碼可讀性差，并且可能導致重構困難。
但是，If-Else 已成為事實上的代碼分支解決方案，這確實是有道理的。這是向所有有抱負的開發(fā)人員講授的第一件事。
不幸的是，許多開發(fā)人員從來沒有前進到更合適的分支策略。有些人的口頭禪是：If-Else 是一把錘子，一切都是釘子。
我將向大家展示一些技巧和模式，這些技巧和模式將終結這種可怕的做法。每個示例的難度都會增加。
完全不必要的 Else 塊
這也許是那些初級開發(fā)人員最負罪的之一。下面的示例很好地說明了當你被認為 If-Else 很棒時會發(fā)生什么：
Simple if-else
Removed else
看起來更專業(yè)吧？你會發(fā)現，實際上根本不需要其他塊。像在這種情況下一樣，你想要在滿足特定條件的情況下執(zhí)行某些操作并立即返回。
價值分配
Value assignment with if-else
If statements with fast return
如果不使用 else，則我們將剩下干凈的可讀代碼。請注意，我也將樣式更改為快速返回而不是單返回語句。如果已經找到正確的值，繼續(xù)測試一個值根本沒有意義。
前提條件檢查
Method without value checks
在沒有價值驗證的情況下執(zhí)行該方法沒有任何意義。因此，在允許方法繼續(xù)執(zhí)行之前，我們需要檢查一些先決條件。
Check preconditions with guard clauses
至此，我們確保僅在值落在預期范圍內時才執(zhí)行主邏輯?，F在，IF 也已被三元代替，因為不再需要在結尾處默認返回"未知"。
將 If-Else 轉換為字典，完全避免 If-Else
也許有人傾向于使用久經考驗的 If-Else。如果添加新操作，則只需簡單地添加其他內容即可。很簡單 但是，就維護而言，這種方法不是一個好的設計。
可讀性已大大提高，并且可以更輕松地推斷出該代碼。注意，僅出于說明目的將字典放置在方法內部。您可能希望從其他地方提供它。
擴展應用程序，完全避免使用 If-Else
這是一個稍微高級的示例。通過用對象替換它們，知道何時甚至完全消除 If。
通常，您會發(fā)現自己不得不擴展應用程序的某些部分。作為初級開發(fā)人員，您可能會傾向于通過添加額外的 If-Else（即 else-if）語句來做到這一點。
舉這個說明性的例子。在這里，我們需要將 Order 實例顯示為字符串。首先，我們只有兩種字符串表示形式：JSON 和純文本。
知道我們需要擴展應用程序的這一部分，這種方法絕對是不可接受的。
上面的代碼不僅違反了"打開/關閉"原則，而且閱讀得不好，還會引起可維護性方面的麻煩。
正確的方法是遵循 SOLID 原則的方法，我們通過實施動態(tài)類型發(fā)現過程（在本例中為策略模式）來做到這一點。
重構這個混亂的過程的過程如下：
使用公共接口將每個分支提取到單獨的策略類中。
動態(tài)查找實現通用接口的所有類。
根據輸入決定執(zhí)行哪種策略。
替換上面示例的代碼如下所示。是的，這是更多代碼的方式。它要求您了解類型發(fā)現的工作原理。但是動態(tài)擴展應用程序是一個高級主題。
讓我們快速瀏覽一下代碼。方法簽名保持不變，因為調用者不需要了解我們的重構。
首先，獲取實現通用接口 IOrderOutputStrategy 的程序集中的所有類型。然后，我們建立一個字典，格式化程序的 displayName 的名稱為 key，類型為 value。
然后從字典中選擇格式化程序類型，然后嘗試實例化策略對象。最后，調用策略對象的 ConvertOrderToString。
最近有讀者想要分布式的項目，還有想要商城的，還有想要springboot,springcloud,k8s等等，這次直接分享幾乎涵蓋了我們java程序員的大部分技術桟，可以說真的非常全面了。強烈建議大家都上手做一做，而且以后肯定用的上。資料包含高清視頻+課件+源碼……
掃以下二維碼并回復“99”即可獲取
掃描上方二維碼，關注并回復【99】馬上獲取
