作者：編走編想來源：https://www.jianshu.com/p/1db0bba283f0

前言

if...else 是所有高級編程語言都有的必備功能。但現實中的代碼往往存在著過多的 if...else。雖然 if...else 是必須的，但濫用 if...else 會對代碼的可讀性、可維護性造成很大傷害，進而危害到整個軟件系統。現在軟件開發領域出現了很多新技術、新概念，但 if...else 這種基本的程序形式并沒有發生太大變化。使用好 if...else 不僅對于現在，而且對于將來，都是十分有意義的。今天我們就來看看如何“干掉”代碼中的 if...else，還代碼以清爽。

問題一：if...else 過多

問題表現

if...else 過多的代碼可以抽象為下面這段代碼。其中只列出5個邏輯分支，但實際工作中，能見到一個方法包含10個、20個甚至更多的邏輯分支的情況。另外，if...else 過多通常會伴隨著另兩個問題：邏輯表達式復雜和 if...else 嵌套過深。對于后兩個問題，本文將在下面兩節介紹。本節先來討論 if...else 過多的情況。

通常，if...else 過多的方法，通常可讀性和可擴展性都不好。從軟件設計角度講，代碼中存在過多的 if...else 往往意味著這段代碼違反了違反單一職責原則和開閉原則。因為在實際的項目中，需求往往是不斷變化的，新需求也層出不窮。所以，軟件系統的擴展性是非常重要的。而解決 if...else 過多問題的最大意義，往往就在于提高代碼的可擴展性。

如何解決

接下來我們來看如何解決 if...else 過多的問題。下面我列出了一些解決方法。

表驅動

職責鏈模式

注解驅動

事件驅動

有限狀態機

Optional

Assert

多態

方法一：表驅動

介紹

對于邏輯表達模式固定的 if...else 代碼，可以通過某種映射關系，將邏輯表達式用表格的方式表示；再使用表格查找的方式，找到某個輸入所對應的處理函數，使用這個處理函數進行運算。

適用場景

邏輯表達模式固定的 if...else

實現與示例

上面的示例使用了 Java 8 的 Lambda 和 Functional Interface，這里不做講解。

表的映射關系，可以采用集中的方式，也可以采用分散的方式，即每個處理類自行注冊。也可以通過配置文件的方式表達。總之，形式有很多。

還有一些問題，其中的條件表達式并不像上例中的那樣簡單，但稍加變換，同樣可以應用表驅動。下面借用《編程珠璣》中的一個稅金計算的例子：

對于上面的代碼，其實只需將稅金的計算公式提取出來，將每一檔的標準提取到一個表格，在加上一個循環即可。具體重構之后的代碼不給出，大家自己思考。

方法二：職責鏈模式

介紹

當 if...else 中的條件表達式靈活多變，無法將條件中的數據抽象為表格并用統一的方式進行判斷時，這時應將對條件的判斷權交給每個功能組件。并用鏈的形式將這些組件串聯起來，形成完整的功能。

適用場景

條件表達式靈活多變，沒有統一的形式。

實現與示例

職責鏈的模式在開源框架的 Filter、Interceptor 功能的實現中可以見到很多。下面看一下通用的使用模式：

當然，示例中的重構前的代碼為了表達清楚，做了一些類和方法的抽取重構。現實中，更多的是平鋪式的代碼實現。

注：職責鏈的控制模式

職責鏈模式在具體實現過程中，會有一些不同的形式。從鏈的調用控制角度看，可分為外部控制和內部控制兩種。

外部控制不靈活，但是減少了實現難度。職責鏈上某一環上的具體實現不用考慮對下一環的調用，因為外部統一控制了。但是一般的外部控制也不能實現嵌套調用。如果有嵌套調用，并且希望由外部控制職責鏈的調用，實現起來會稍微復雜。具體可以參考 Spring Web Interceptor 機制的實現方法。

內部控制就比較靈活，可以由具體的實現來決定是否需要調用鏈上的下一環。但如果調用控制模式是固定的，那這樣的實現對于使用者來說是不便的。

設計模式在具體使用中會有很多變種，大家需要靈活掌握

方法三：注解驅動

介紹

通過 Java 注解(或其它語言的類似機制)定義執行某個方法的條件。在程序執行時，通過對比入參與注解中定義的條件是否匹配，再決定是否調用此方法。具體實現時，可以采用表驅動或職責鏈的方式實現。

適用場景

適合條件分支很多多，對程序擴展性和易用性均有較高要求的場景。通常是某個系統中經常遇到新需求的核心功能。

實現與示例

很多框架中都能看到這種模式的使用，比如常見的 Spring MVC。因為這些框架很常用，demo 隨處可見，所以這里不再上具體的演示代碼了。

這個模式的重點在于實現。現有的框架都是用于實現某一特定領域的功能，例如 MVC。故業務系統如采用此模式需自行實現相關核心功能。主要會涉及反射、職責鏈等技術。具體的實現這里就不做演示了。

方法四：事件驅動

介紹

通過關聯不同的事件類型和對應的處理機制，來實現復雜的邏輯，同時達到解耦的目的。

適用場景

從理論角度講，事件驅動可以看做是表驅動的一種，但從實踐角度講，事件驅動和前面提到的表驅動有多處不同。具體來說：

表驅動通常是一對一的關系；事件驅動通常是一對多；

表驅動中，觸發和執行通常是強依賴；事件驅動中，觸發和執行是弱依賴

正是上述兩者不同，導致了兩者適用場景的不同。具體來說，事件驅動可用于如訂單支付完成觸發庫存、物流、積分等功能。

實現與示例

實現方式上，單機的實踐驅動可以使用 Guava、Spring 等框架實現。分布式的則一般通過各種消息隊列方式實現。但是因為這里主要討論的是消除 if...else，所以主要是面向單機問題域。因為涉及具體技術，所以此模式代碼不做演示。

方法五：有限狀態機

介紹

有限狀態機通常被稱為狀態機(無限狀態機這個概念可以忽略)。先引用維基百科上的定義：

有限狀態機(英語：finite-state machine，縮寫：FSM)，簡稱狀態機，是表示有限個狀態以及在這些狀態之間的轉移和動作等行為的數學模型。

其實，狀態機也可以看做是表驅動的一種，其實就是當前狀態和事件兩者組合與處理函數的一種對應關系。當然，處理成功之后還會有一個狀態轉移處理。

適用場景

雖然現在互聯網后端服務都在強調無狀態，但這并不意味著不能使用狀態機這種設計。其實，在很多場景中，如協議棧、訂單處理等功能中，狀態機有這其天然的優勢。因為這些場景中天然存在著狀態和狀態的流轉。

實現與示例

實現狀態機設計首先需要有相應的框架，這個框架需要實現至少一種狀態機定義功能，以及對于的調用路由功能。狀態機定義可以使用 DSL 或者注解的方式。原理不復雜，掌握了注解、反射等功能的同學應該可以很容易實現。

參考技術：

• Apache Mina State Machine Apache Mina 框架，雖然在 IO 框架領域不及 Netty，但它卻提供了一個狀態機的功能。https://mina.apache.org/mina-project/userguide/ch14-state-machine/ch14-state-machine.html。有自己實現狀態機功能的同學可以參考其源碼。
• Spring State Machine Spring 子項目眾多，其中有個不顯山不露水的狀態機框架 —— Spring State Machine https://projects.spring.io/spring-statemachine/。可以通過 DSL 和注解兩種方式定義。

上述框架只是起到一個參考的作用，如果涉及到具體項目，需要根據業務特點自行實現狀態機的核心功能。

方法六：Optional

介紹

Java 代碼中的一部分 if...else 是由非空檢查導致的。因此，降低這部分帶來的 if...else 也就能降低整體的 if...else 的個數。

Java 從 8 開始引入了 Optional 類，用于表示可能為空的對象。這個類提供了很多方法，用于相關的操作，可以用于消除 if...else。開源框架 Guava 和 Scala 語言也提供了類似的功能。

使用場景

有較多用于非空判斷的 if...else。

實現與示例

傳統寫法：

使用 Optional 之后：

Optional strOptional = Optional.of("Hello World!");strOptional.ifPresentOrElse(System.out::println, () -> System.out.println("Null"));

Optional 還有很多方法，這里不一一介紹了。但請注意，不要使用 get() 和 isPresent() 方法，否則和傳統的 if...else 無異。

擴展：Kotlin Null Safety

Kotlin 帶有一個被稱為 Null Safety 的特性：

bob?.department?.head?.name

對于一個鏈式調用，在 Kotlin 語言中可以通過 ?. 避免空指針異常。如果某一環為 null，那整個鏈式表達式的值便為 null。

方法七：Assert 模式

介紹

上一個方法適用于解決非空檢查場景所導致的 if...else，類似的場景還有各種參數驗證，比如還有字符串不為空等等。很多框架類庫，例如 Spring、Apache Commons 都提供了工具里，用于實現這種通用的功能。這樣大家就不必自行編寫 if...else 了。

• Apache Commons Lang 中的 Validate 類：https://commons.apache.org/proper/commons-lang/javadocs/api-3.1/org/apache/commons/lang3/Validate.html
• Spring 的 Assert 類：https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/util/Assert.html

使用場景

通常用于各種參數校驗

擴展：Bean Validation

類似上一個方法，介紹 Assert 模式順便介紹一個有類似作用的技術 —— Bean Validation。Bean Validation 是 Java EE 規范中的一個。Bean Validation 通過在 Java Bean 上用注解的方式定義驗證標準，然后通過框架統一進行驗證。也可以起到了減少 if...else 的作用。

方法八：多態

介紹

使用面向對象的多態，也可以起到消除 if...else 的作用。在代碼重構這本書中，對此也有介紹：https://refactoring.com/catalog/replaceConditionalWithPolymorphism.html

使用場景

鏈接中給出的示例比較簡單，無法體現適合使用多態消除 if...else 的具體場景。一般來說，當一個類中的多個方法都有類似于示例中的 if...else 判斷，且條件相同，那就可以考慮使用多態的方式消除 if...else。

同時，使用多態也不是徹底消除 if...else。而是將 if...else 合并轉移到了對象的創建階段。在創建階段的 if..，我們可以使用前面介紹的方法處理。

小結

上面這節介紹了 if...else 過多所帶來的問題，以及相應的解決方法。除了本節介紹的方法，還有一些其它的方法。比如，在《重構與模式》一書中就介紹了“用 Strategy 替換條件邏輯”、“用 State 替換狀態改變條件語句”和“用 Command 替換條件調度程序”這三個方法。其中的“Command 模式”，其思想同本文的“表驅動”方法大體一致。另兩種方法，因為在《重構與模式》一書中已做詳細講解，這里就不再重復。

何時使用何種方法，取決于面對的問題的類型。上面介紹的一些適用場景，只是一些建議，更多的需要開發人員自己的思考。

問題二：if...else 嵌套過深

問題表現

if...else 多通常并不是最嚴重的的問題。有的代碼 if...else 不僅個數多，而且 if...else 之間嵌套的很深，也很復雜，導致代碼可讀性很差，自然也就難以維護。

if...else 嵌套過深會嚴重地影響代碼的可讀性。當然，也會有上一節提到的兩個問題。

如何解決

上一節介紹的方法也可用用來解決本節的問題，所以對于上面的方法，此節不做重復介紹。這一節重點一些方法，這些方法并不會降低 if...else 的個數，但是會提高代碼的可讀性：

抽取方法

衛語句

方法一：抽取方法

介紹

抽取方法是代碼重構的一種手段。定義很容易理解，就是將一段代碼抽取出來，放入另一個單獨定義的方法。借用 https://refactoring.com/catalog/extractMethod.html 中的定義：

適用場景

if...else 嵌套嚴重的代碼，通常可讀性很差。故在進行大型重構前，需先進行小幅調整，提高其代碼可讀性。抽取方法便是最常用的一種調整手段。

實現與示例

方法二：衛語句

介紹

在代碼重構中，有一個方法被稱為“使用衛語句替代嵌套條件語句”https://refactoring.com/catalog/replaceNestedConditionalWithGuardClauses.html。直接看代碼：

使用場景

當看到一個方法中，某一層代碼塊都被一個 if...else 完整控制時，通常可以采用衛語句。

問題三：if...else 表達式過于復雜

問題表現

if...else 所導致的第三個問題來自過于復雜的條件表達式。下面給個簡單的例子，當 condition 1、2、3、4 分別為 true、false，請大家排列組合一下下面表達式的結果。

if ((condition1 && condition2 ) || ((condition2 || condition3) && condition4)) { }

我想沒人愿意干上面的事情。關鍵是，這一大坨表達式的含義是什么？關鍵便在于，當不知道表達式的含義時，沒人愿意推斷它的結果。

所以，表達式復雜，并不一定是錯。但是表達式難以讓人理解就不好了。

如何解決

對于 if...else 表達式復雜的問題，主要用代碼重構中的抽取方法、移動方法等手段解決。因為這些方法在《代碼重構》一書中都有介紹，所以這里不再重復。

總結

本文一個介紹了10種(算上擴展有12種)用于消除、簡化 if...else 的方法。還有一些方法，如通過策略模式、狀態模式等手段消除 if...else 在《重構與模式》一書中也有介紹。

正如前言所說，if...else 是代碼中的重要組成部分，但是過度、不必要地使用 if...else，會對代碼的可讀性、可擴展性造成負面影響，進而影響到整個軟件系統。

“干掉”if...else 的能力高低反映的是程序員對軟件重構、設計模式、面向對象設計、架構模式、數據結構等多方面技術的綜合運用能力，反映的是程序員的內功。要合理使用 if...else，不能沒有設計，也不能過度設計。這些對技術的綜合、合理地運用都需要程序員在工作中不斷的摸索總結。

總結

以上是生活随笔為你收集整理的if else if else语句格式_如何“干掉”if...else的全部內容，希望文章能夠幫你解決所遇到的問題。

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