設計更好的軟體，取代If-Else的5種方法。入門到高級範例
讓我直接說這句話：If-Else通常是一個糟糕的選擇。
它導致設計複雜，程式碼可讀性差，並且可能導致重構困難。
但是，If-Else已成為事實上的程式碼分支解決方案，這確實是有道理的。這是向所有有抱負的開發人員講授的第一件事。不幸的是，許多開發人員從來沒有前進到更合適的分支策略。
有些人的口頭禪是：If-Else是一把錘子，一切都是釘子。
無法區分何時使用更合適的方法是區分大三學生和大三學生的原因之一。
我將向您展示一些技巧和模式，這些技巧和模式將終結這種可怕的做法。
每個範例的難度都會增加。
這也許是那些初級開發人員最負罪的之一。下面的範例很好地說明了當您被認為If-Else很棒時會發生什麼。
只需刪除else`區塊即可簡化此過程。
看起來更專業吧？
您會經常發現，實際上根本不需要其他區塊。像在這種情況下一樣，您想要在滿足特定條件的情況下執行某些操作並立即返回。
如果您要根據提供的某些輸入為變數分配新值，請停止If-Else廢話-一種更具可讀性的方法。
儘管很簡單，但它卻很糟糕。首先，If-Else很容易在這裡被開關取代。但是，我們可以透過完全刪除else來進一步簡化此程式碼。
如果不使用else，則我們將剩下乾淨的可讀程式碼。請注意，我也將樣式更改為快速返回而不是單返回語句-如果已經找到正確的值，繼續測試一個值根本沒有意義。
#通常，我發現，如果方法提供了無效的值，則繼續執行是沒有意義的。
假設我們從以前就有了DefineGender方法，要求提供的輸入值必須永遠為0或1。
在沒有價值驗證的情況下執行方法沒有任何意義。因此，在允許方法繼續執行之前，我們需要檢查一些先決條件。
套用保護子句防禦性編碼技術，您將檢查方法的輸入值，然後繼續執行方法。
至此，我們確保只有在值落在預期範圍內時才執行主邏輯。
現在，IF也已被三元代替，因為不再需要在結尾處預設回傳"未知"。
假設您需要執行一些操作，這些操作將根據某些條件進行選擇，我們知道以後必須添加更多操作。
也許有人傾向於使用久經考驗的If-Else。如果新增操作，只需簡單地新增其他內容即可。很簡單 但是，就維護而言，這種方法不是一個好的設計。
知道我們以後需要新增新的動作後，我們可以將If-Else重構為字典。
可讀性已大大提高，並且可以更輕鬆地推斷出該程式碼。
注意，僅出於說明目的將字典放置在方法內部。您可能希望從其他地方提供它。
這是一個稍微進階的範例。
透過用物件替換它們，知道何時甚至完全消除If。
通常，您會發現自己必須擴展應用程式的某些部分。作為初級開發人員，您可能會傾向於透過添加額外的If-Else（即else-if）語句來做到這一點。
舉出這個說明性的例子。在這裡，我們需要將Order實例顯示為字串。首先，我們只有兩種字串表示形式：JSON和純文字。在此階段使用If-Else並不是什麼大問題，如果我們可以輕鬆替換其他，只要如前所述即可。
知道我們需要擴充應用程式的這一部分，這種方法絕對是不可接受的。
上面的程式碼不僅違反了"開啟/關閉"原則，而且閱讀得不好，還會造成可維護性方面的麻煩。
正確的方法是遵循SOLID原則的方法-我們透過實施動態類型發現過程（在本例中為策略模式）來做到這一點。
重構這個混亂的過程的過程如下：
· 使用公共介面將每個分支提取到單獨的策略類別中
· 動態查找實現通用介面的所有類別
· 根據輸入決定執行哪種策略
取代上面範例的程式碼如下所示。是的，這是更多代碼的方式。它要求您了解類型發現的工作原理。但是動態擴展應用程式是一個高級主題。
我只顯示將替換If-Else範例的確切部分。如果您想查看所有涉及的對象，請查看此要點。
讓我們快速瀏覽程式碼。
方法簽章保持不變，因為呼叫者不需要了解我們的重構。
首先，取得實作通用介面IOrderOutputStrategy的程式集中的所有類型。然後，我們建立一個字典，格式化程式的displayName的名稱為key，類型為value。
然後從字典中選擇格式化程式類型，然後嘗試實例化策略物件。
最後，呼叫策略物件的ConvertOrderToString。
以上是我們公司如何把專案中的2000個if-else徹底幹掉的?的詳細內容。更多資訊請關注PHP中文網其他相關文章！
