★★★建議星標我們★★★
Java進階架構師★「星標」!這樣才不會錯過每日進階架構文章呀。
2020年Java原創面試題庫連載中
【000期】Java最全面試題庫思維導圖
【020期】JavaSE系列面試題匯總(共18篇)
【028期】JavaWeb系列面試題匯總(共10篇)
【042期】JavaEE系列面試題匯總(共13篇)
【049期】資料庫系列面試題匯總(共6篇)
【053期】中間件系列面試題匯總(共3篇)
【065期】數據結構與算法面試題匯總(共11篇)
【076期】分布式面試題匯總(共10篇)
【100期】綜合面試題系列匯總(共23篇)
【151期】100-150期匯總(共50篇)
【152期】如何應對高並發流量?
【153期】StringBuilder線程安全嗎?為什麼?
【154期】Redis的過期鍵刪除策略有哪些?
【155期】Spring-Retry重試實現原理是什麼?
【156期】資料庫分庫分表之後,如何解決事務問題?
【157期】為什麼 SQL 語句不要過多的 join?
【158期】說說註冊中心 zookeeper 和 eureka 中的CP和 AP
【159期】Java中的finally一定會被執行嗎?
更多內容,點擊上方名片查看
導讀
當else多了之後,看起來代碼就開始複雜了,那麼如何來完成同樣的邏輯呢?看看這篇文章,也許你就會有所領悟!
來源:翻譯自: Nicklas Millard 的文章《Better Software Without If-Else》
註:本文並不肯定或者否定哪一種寫法,僅僅為大家提供一些其他的編碼思路或者一些值得借鑑的點子,希望大家能在公眾號的每一篇文章中都能有所收穫,同時歡迎探討!
設計更好的軟體,替換 If-Else 的 5 種方法。入門到高級示例
讓我直接說這句話:If-Else 通常是一個糟糕的選擇。
它導致設計複雜,代碼可讀性差,並且可能導致重構困難。
但是,If-Else 已成為事實上的代碼分支解決方案,這確實是有道理的。這是向所有有抱負的開發人員講授的第一件事。不幸的是,許多開發人員從來沒有前進到更合適的分支策略。
有些人的口頭禪是:If-Else 是一把錘子,一切都是釘子。
無法區分何時使用更合適的方法是區分大三學生和大三學生的原因之一。
我將向您展示一些技巧和模式,這些技巧和模式將終結這種可怕的做法。
每個示例的難度都會增加。
搜索公縱號:MarkerHub,關注回復[ vue ]獲取前後端入門教程!
1 完全不必要的 Else 塊
這也許是那些初級開發人員最負罪的之一。下面的示例很好地說明了當您被認為 If-Else 很棒時會發生什麼。
Simple if-else
只需刪除 else` 塊即可簡化此過程。
Removed else
看起來更專業吧?
您會經常發現,實際上根本不需要其他塊。像在這種情況下一樣,您想要在滿足特定條件的情況下執行某些操作並立即返回。
2 價值分配
如果您要根據提供的某些輸入為變量分配新值,請停止 If-Else 廢話 – 一種更具可讀性的方法。
Value assignment with if-else
儘管很簡單,但它卻很糟糕。首先,If-Else 很容易在這里被開關取代。但是,我們可以通過完全刪除 else 來進一步簡化此代碼。
If statements with fast return
如果不使用 else,則我們將剩下乾淨的可讀代碼。請注意,我也將樣式更改為快速返回而不是單返回語句 – 如果已經找到正確的值,繼續測試一個值根本沒有意義。
3 前提條件檢查
通常,我發現,如果方法提供了無效的值,則繼續執行是沒有意義的。假設我們從以前就有了 DefineGender 方法,要求提供的輸入值必須始終為 0 或 1。
Method without value checks
在沒有價值驗證的情況下執行該方法沒有任何意義。因此,在允許方法繼續執行之前,我們需要檢查一些先決條件。
應用保護子句防禦性編碼技術,您將檢查方法的輸入值,然後繼續執行方法。
Check preconditions with guard clauses
至此,我們確保僅在值落在預期範圍內時才執行主邏輯。
現在,IF 也已被三元代替,因為不再需要在結尾處默認返回 “未知”。
4 將 If-Else 轉換為字典—完全避免 If-Else
假設您需要執行一些操作,這些操作將根據某些條件進行選擇,我們知道以後必須添加更多操作。
也許有人傾向於使用久經考驗的 If-Else。如果添加新操作,則只需簡單地添加其他內容即可。很簡單 但是,就維護而言,這種方法不是一個好的設計。
知道我們以後需要添加新的操作後,我們可以將 If-Else 重構為字典。
可讀性已大大提高,並且可以更輕鬆地推斷出該代碼。
「
注意,僅出於說明目的將字典放置在方法內部。您可能希望從其他地方提供它。
」
5 擴展應用程式—完全避免使用 If-Else
這是一個稍微高級的示例。
通過用對象替換它們,知道何時甚至完全消除 If。
通常,您會發現自己不得不擴展應用程式的某些部分。作為初級開發人員,您可能會傾向於通過添加額外的 If-Else(即 else-if)語句來做到這一點。
舉這個說明性的例子。在這里,我們需要將 Order 實例顯示為字符串。首先,我們只有兩種字符串表示形式:JSON 和純文本。在此階段使用 If-Else 並不是什麼大問題,如果我們可以輕鬆替換其他,只要如前所述即可。
知道我們需要擴展應用程式的這一部分,這種方法絕對是不可接受的。
上面的代碼不僅違反了 “打開 / 關閉” 原則,而且閱讀得不好,還會引起可維護性方面的麻煩。
正確的方法是遵循 SOLID 原則的方法 – 我們通過實施動態類型發現過程(在本例中為策略模式)來做到這一點。
重構這個混亂的過程的過程如下:
-
使用公共接口將每個分支提取到單獨的策略類中
-
動態查找實現通用接口的所有類
-
根據輸入決定執行哪種策略
-
替換上面示例的代碼如下所示。是的,這是更多代碼的方式。它要求您了解類型發現的工作原理。但是動態擴展應用程式是一個高級主題。
我只顯示將替換 If-Else 示例的確切部分。如果要查看所有涉及的對象,請查看此要點。
讓我們快速瀏覽一下代碼。
方法簽名保持不變,因為調用者不需要了解我們的重構。
首先,獲取實現通用接口 IOrderOutputStrategy 的程序集中的所有類型。然後,我們建立一個字典,格式化程序的 displayName 的名稱為 key,類型為 value。
然後從字典中選擇格式化程序類型,然後嘗試實例化策略對象。
最後,調用策略對象的 ConvertOrderToString。
作者介紹:
Nicklas Millard 在丹麥的四大諮詢公司之一中擔任高級技術顧問。他主要擔任客戶項目的首席開發人員和解決方案架構師。
他一直在為商業客戶和政府機構開發軟體,例如國防部,教育部,丹麥環境與食品部,國家警察,丹麥勞動力市場和招聘局以及 rstad。
來源:kknews編寫 if 時不帶 else,你的代碼會更好