點選「 IT碼徒 」， 關註，置頂 公眾號

每日技術幹貨，第一時間送達！

1 前言

If-Else 通常是一個糟糕的選擇，它導致設計復雜，程式碼可讀性差，並且可能導致重構困難。

但是，If-Else 已成為事實上的代分碼支解決方案，這確實是有道理的。這是向所有有抱負的開發人員講授的第一件事。

不幸的是，許多開發人員從來沒有前進到更合適的分支策略。有些人的口頭禪是：If-Else 是一把錘子，一切都是釘子。

我將向大家展示一些技巧和模式，這些技巧和模式將終結這種可怕的做法。每個範例的難度都會增加。

2 完全不必要的 Else 塊

這也許是那些初級開發人員最負罪的之一。 下面的範例很好地說明了當你被認為 If-Else 很棒時會發生什麽：

只需刪除 else 塊即可簡化此過程，如下圖：

看起來更專業吧？你會發現，實際上根本不需要其他塊。像在這種情況下一樣，你想要在滿足特定條件的情況下執行某些操作並立即返回。

3 價值分配

如果你要根據提供的某些輸入為變量分配新值，請停止 If-Else 廢話，一種更具可讀性的方法。

盡管很簡單，但它卻很糟糕。首先，If-Else 很容易在這裏被開關取代。但是，我們可以透過完全刪除 else 來進一步簡化此程式碼。

如果不使用 else，則我們將剩下幹凈的可讀程式碼。請註意，我也將樣式更改為快速返回而不是單返回語句。如果已經找到正確的值，繼續測試一個值根本沒有意義。

4 前提條件檢查

通常，我發現，如果方法提供了無效的值，則繼續執行是沒有意義的。 假設我們從以前就有了 DefineGender 方法，要求提供的輸入值必須始終為 0 或 1。

在沒有價值驗證的情況下執行該方法沒有任何意義。因此，在允許方法繼續執行之前，我們需要檢查一些先決條件。

套用保護子句防禦性編碼技術，你將檢查方法的輸入值，然後繼續執行方法。

至此，我們確保僅在值落在預期範圍內時才執行主邏輯。現在，IF 也已被三元代替，因為不再需要在結尾處預設返回"未知"。

將 If-Else 轉換為字典，完全避免 If-Else

假設您需要執行一些操作，這些操作將根據某些條件進行選擇，我們知道以後必須添加更多操作。

也許有人傾向於使用久經考驗的 If-Else。如果添加新操作，則只需簡單地添加其他內容即可。很簡單 但是，就維護而言，這種方法不是一個好的設計。

知道我們以後需要添加新的操作後，我們可以將 If-Else 重構為字典。

可讀性已大大提高，並且可以更輕松地推斷出該程式碼。註意，僅出於說明目的將字典放置在方法內部。您可能希望從其他地方提供它。

擴充套件應用程式，完全避免使用 If-Else

這是一個稍微高級的範例。透過用物件替換它們，知道何時甚至完全消除 If。

通常，您會發現自己不得不擴充套件應用程式的某些部份。作為初級開發人員，您可能會傾向於透過添加額外的 If-Else（即 else-if）語句來做到這一點。

舉這個說明性的例子。在這裏，我們需要將 Order 例項顯示為字串。首先，我們只有兩種字串表示形式：JSON 和純文本。

5 最後

在此階段使用 If-Else 並不是什麽大問題，如果我們可以輕松替換其他，只要如前所述即可。

知道我們需要擴充套件應用程式的這一部份，這種方法絕對是不可接受的。

上面的程式碼不僅違反了"開啟/關閉"原則，而且閱讀得不好，還會引起可維護性方面的麻煩。

正確的方法是遵循 SOLID 原則的方法，我們透過實施動態型別發現過程（在本例中為策略模式）來做到這一點。

重構這個混亂的過程的過程如下：

替換上面範例的程式碼如下所示。是的，這是更多程式碼的方式。它要求您了解型別發現的工作原理。但是動態擴充套件應用程式是一個高級主題。

我只顯示將替換 If-Else 範例的確切部份。如果要檢視所有涉及的物件，請檢視此要點。

讓我們快速瀏覽一下程式碼。方法簽名保持不變，因為呼叫者不需要了解我們的重構。

首先，獲取實作通用介面 IOrderOutputStrategy 的程式集中的所有型別。然後，我們建立一個字典，格式化程式的 displayName 的名稱為 key，型別為 value。

然後從字典中選擇格式化程式型別，然後嘗試例項化策略物件。最後，呼叫策略物件的 ConvertOrderToString。

來源： blog.csdn.net/wantflydacheng/article/details/111306370

— END —

PS：防止找不到本篇文章，可以收藏點贊，方便翻閱尋找哦。

往期推薦