來自公眾號：51CTO技術棧

作者：Nicklas Millard，在丹麥的四大咨詢公司之一中擔任高級技術顧問，主要擔任客戶項目的首席開發人員和解決方案架構師。

編輯：陶家龍

出處：https://medium.com/swlh/5-ways-to-replace-if-else-statements-857c0ff19357

“

本文并不肯定或者否定哪一種寫法，僅僅為大家提供一些其他的編碼思路或者一些值得借鑒的點子。

設計更好的軟件，替換 If-Else 的 5 種方法，從入門到高級示例

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

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

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

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

完全不必要的 Else 塊

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

Simple if-else

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

Removed else

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

價值分配

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

Value assignment with if-else

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

If statements with fast return

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

前提條件檢查

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

Method without value checks

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

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

Check preconditions with guard clauses

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

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

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

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

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

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

擴展應用程序，完全避免使用 If-Else

這是一個稍微高級的示例。通過用對象替換它們，知道何時甚至完全消除 If。

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

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

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

知道我們需要擴展應用程序的這一部分，這種方法絕對是不可接受的。

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

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

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

• 使用公共接口將每個分支提取到單獨的策略類中。

• 動態查找實現通用接口的所有類。

• 根據輸入決定執行哪種策略。

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

我只顯示將替換 If-Else 示例的確切部分。如果要查看所有涉及的對象，請查看此要點。

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

首先，獲取實現通用接口 IOrderOutputStrategy 的程序集中的所有類型。然后，我們建立一個字典，格式化程序的 displayName 的名稱為 key，類型為 value。

然后從字典中選擇格式化程序類型，然后嘗試實例化策略對象。最后，調用策略對象的 ConvertOrderToString。

- EOF -

想要加入中生代架構群的小伙伴，請添加群合伙人大白的微信

申請備注（姓名+公司+技術方向）才能通過哦！

阿里技術精彩文章推薦

往期推薦

深度：揭秘阿里巴巴的客群畫像

多隆：從工程師到阿里巴巴合伙人

阿里技術專家楚衡：架構制圖的工具與方法論

螞蟻集團技術專家山丘：性能優化常見壓測模型及優缺點

阿里文娛技術專家戰獒: 領域驅動設計詳解之What, Why, How?

阿里專家馬飛翔：一文讀懂架構整潔之道

阿里專家常昊：新人如何上手項目管理？

螞蟻集團沈凋墨：Kubernetes-微內核的分布式操作系統

阿里合伙人范禹：常掛在阿里技術人嘴邊的四句土話

阿里技術專家都鐸：一文搞懂技術債

支付寶研究員兼OceanBase總架構師楊傳輝：我在數據庫夢之隊的十年成長路

阿里技術專家麒燁：修煉測試基本功

阿里計算平臺掌門人賈揚清：我對人工智能方向的一點淺見

螞蟻資深算法專家周俊：從原理到落地，支付寶如何打造保護隱私的共享智能？

阿里高級技術專家簫逸：如何畫好一張架構圖？

阿里高級技術專家張建飛：應用架構分離業務邏輯和技術細節之道

螞蟻科技 Service Mesh 落地實踐與挑戰 | GIAC 實錄

阿里6年，我的技術蛻變之路！

螞蟻集團涵暢：再啟程，Service Mesh 前路雖長，尤可期許

阿里P9專家右軍：大話軟件質量穩定性

阿里合伙人程立：阿里15年，我撕掉了身上兩個標簽

阿里高工流生 | 云原生時代的 DevOps 之道

阿里高級技術專家邱小俠：微服務架構的理論基礎 - 康威定律

阿里P9專家右軍：以終為始的架構設計

阿里P8架構師：淘寶技術架構從1.0到4.0的架構變遷！12頁PPT詳解

阿里技術：如何畫出一張合格的技術架構圖？

螞蟻資深技術專家王旭：開源項目是如何讓這個世界更安全的？

阿里資深技術專家崮德：8 個影響我職業生涯的重要技能

儒梟：我看技術人的成長路徑

阿里高級技術專家宋意：平凡人在阿里十年的成長之旅

阿里技術專家甘盤：淺談雙十一背后的支付寶LDC架構和其CAP分析

阿里技術專家光錐：億級長連網關的云原生演進之路

阿里云原生張羽辰：服務發現技術選型那點事兒

螞蟻研究員玉伯：做一個簡單自由有愛的技術人

阿里高級技術專家至簡: Service Mesh 在超大規模場景下的落地挑戰

阿里巴巴山獵：手把手教你玩轉全鏈路監控

阿里涉江：你真的會學習嗎？從結構化思維說起

螞蟻金服資深技術專家經國：云原生時代微服務的高可用架構設計

深入分布式緩存之EVCache探秘開局篇

? ?END ? ?? #架構師必備#

新人創作打卡挑戰賽發博客就能抽獎！定制產品紅包拿不停！

總結

以上是生活随笔為你收集整理的CTO怒了：再写if-else，逮着罚款1000！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。