无需If-Else语句，状态模式即可编写干净可维护的代码

If-Else语句我们再熟悉不过了，你可能看过无数的相关教程，读过很多编程书籍，来提升将If-Else用作de facto分支技术的方法，甚至可能你的默认模式就是使用If-Else。

可以结束这一切了。在任何新的条件要求下，使用If-Else都会增加复杂性。用状态对象来代替If-Else吧。应用状态模式，你只需使用专用状态对象而无需使用If-Else语句来更改对象行为。

[[334050]]

像下面这样的代码时代已经一去不复返了：

触发PTSD警告

你肯定曾经写过更复杂的分支，我也曾是这么做的。上面的分支逻辑甚至还不是很复杂，但如果尝试添加新条件，事情肯定会越弄越糟。

另外，如果你认为创建新类而非简单地使用分支语句听起来很烦人，那么请一定等到实际使用的时候，你会发现这种方法简洁而优雅。除了“ D”部分之外，它还将使你的代码库更加扎实。

那么如何避免混乱的分支代码呢?

我们将研究如何在生产就绪代码中替换If-Else分支。这是一个虚构的例子，但是方法与我在大型客户的代码库中使用的方法相同。

创建一个非常简单的Booking类，其中包含一些状态。它还有两个公共方法：Accept()and Cancel().。我尽力绘制了一个图表，显示了预订可能处于的不同状态。

代码中重构分支逻辑的过程一共有三步：

• 创建一个抽象基类
• 将每个状态实现为继承自基本状态的单独类
• 让Booking`类具有私有或内部方法，该方法以状态基类为参数

演示时间到!

首先，需要一个将继承所有状态的基类。

请注意，该基类还具有两种方法，Accept和Cancel——尽管此处将它们标记为内部。此外，基态具有“特殊” EnterState(Booking booking)方法。每当将新状态分配给预订对象时，就会调用此方法。

其次，为要代表的每个状态创建单独的类。

注意，如上图所示，每个类如何表示一个状态。此外，ExpiredState和CancelledState不会将预订转换为新状态。这两类在本质上与Null Object Pattern非常相似。

最后，预订类型本身。

看到预订类型如何简单地将Accept和Cancel的实现委派给其状态对象了吗?这样做可以使我们删除许多条件逻辑，并使每个状态仅关注对自己重要的事情，当前状态也有机会将预订过渡到新状态。

Q&A

1. 如何处理新的条件功能?

如果说通常需要使用某些条件检查来实现新功能，那么现在只需创建一个新的状态类即可，你将不再需要费力地处理if-else语句了。

2. 如何将状态对象保留在数据库中?

不，你不想。

当将对象保存到例如SQL或NoSQL数据库时，状态对象并不重要，这时只有了解对象的状态及其应如何映射到列是重要的。你可以将状态映射到友好类型名称，枚举或整数。只要你愿意，总有某种方法可以将保存的值转换回状态对象。

3. 但是你还在使用If’s吗?

它们是必不可少的，特别是当用作保护子句时。但If-Else组合是造成可维护性难题的根本原因。

[[334051]]

图源：unsplash

复杂性不是源于你拥有的类的数量，而是源于这些类承担的功能。拥有许多专门的类将使你的代码库更具可读性与可维护性，并且从总体上来说，也更易于使用。

适时地和If-Else语句说再见吧!