你也許已經看了無數使用 if-else 語句的教程，你可能也讀過不少使用 if-else 作為事實上的分支技術的編程書籍。

[[347735]] 

圖片來自 Pexels

它可能是也是你日常默認的編碼模式。但是，讓我們從今天起結束這種方法，用狀態對象代替 If-else。

請注意，如果你正在編寫的代碼需要根據當前狀態改變其實現的類，你需要改用這種方法。如果你的代碼不是處理對象的狀態變化，你需要選擇其他方法。

即使你已經聽說過狀態模式，你可能也想了解如何在生產代碼中實現。

對于以前了解不多的人，下面有一段非常簡單的介紹。

對 if-else 增加任何新的條件，都會增加復雜性。應用狀態模式(state pattern)，你只需使用專門的狀態對象，代替 if-else 語句來改變一個對象的行為。

像下面這樣代碼的日子，已經一去不復返了：

 

警告：PTSD 觸發器。另外，希望你能發現里面的邏輯錯誤(除了代碼整體一團糟)。

你以前肯定寫過更復雜的分支。我幾年前確實寫過。

上面的分支邏輯雖然不是很復雜，但如果再添加新的條件，這個邏輯會更加混亂。

另外，如果你認為創建新的類，而不是簡單地使用分支語句聽起來很煩人，那就可以繼續看下面的實際代碼，它簡潔而優雅。

更妙的是，它會讓你的代碼庫變得更 SOLID，除了 "D" 部分。

"好了，我相信 if-else 是邪惡的，現在請告訴我如何避免混亂的分支代碼"!

我們將看看我是如何在生產代碼中替換 if-else 分支的。這是一個假想的例子，但方法和我在大型客戶的代碼庫中使用的是一樣的。

讓我們創建一個非常簡單的 Booking 類，它有幾個狀態。它也會有兩個公共方法：Accept() 和 Cancel()。

我畫了一個圖，顯示了一個預訂可能處于的不同狀態：

 

將分支邏輯從代碼中重構出來，可以分為三步：

• 創建一個抽象的基本狀態類。
• 將每個狀態作為一個獨立的類來實現，繼承于基本狀態。
• 讓 Booking 類有一個私有的或內部的方法，把狀態基類作為參數。

演示時間

首先，我們需要一個用于繼承所有狀態的基礎狀態類。

 

請注意這個基類也有 Accept 和 Cancel 這兩個方法，雖然這里它們被標記為內部方法。

此外，基礎狀態有一個特殊的 EnterState(Booking booking)方法。每當一個新的狀態被分配給預訂對象時，這個方法就會被調用。

其次，我們要為我們要表示的每一個狀態單獨做一個類。

請注意每個類是如何代表一個狀態的，就像上圖描述的那樣。另外，CancelledState 不會不允許預訂再轉換到一個新的狀態。這個類的設計與 Null Object Pattern 非常相似。 

最后，再看看 Booking 類本身： 

看到 Booking 類是如何簡單地將 Accept 和 Cancel 的實現委托給它的狀態對象的嗎? 

這樣做可以讓我們去掉很多條件邏輯，讓每個狀態只關注對自己重要的東西 -- 當前狀態，以及也有可能將預訂轉換到新的狀態。

如何處理新的條件功能?

如果新功能通常會使用一些條件檢查來實現，現在你可以直接創建一個新的狀態類。

就這么簡單。你將不再需要處理笨重的 if-else 語句。

如何將狀態對象持久化在數據庫中?

不需要。

當把一個對象保存到 SQL 或 NoSQL 數據庫時，狀態對象并不重要。只有知道對象的狀態，以及如何將其映射到列才是重要的。

你可以將狀態映射到一個友好的類型名、一個枚舉或一個整型。只要你有某種方法將保存的值轉換回狀態對象，那就任何方法都行。

但為什么你還在使用 if?

是的，if 有時是必不可少的，尤其是作為防護語句(guard clause)使用時。if-else 組合才是讓人頭疼的可維護性的根本原因。

但是文中介紹的方法會帶來很多額外的類?

的確如此。正如我在另一篇文章中提到的，復雜性并不源于你擁有的類的數量，而是源于這些類所承擔的責任。

擁有許多專門的類，會讓你的代碼庫更易讀、更易維護，而且整體上更容易讓人喜歡。

作者：Nicklas Millard

編輯：陶家龍

出處：轉載自公眾號高可用架構(ID：ArchNotes)