你也许已经看了无数使用 if-else 语句的教程，你可能也读过不少使用 if-else 作为事实上的分支技术的编程书籍。
图片来自 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)
