消除if...else的⼗种⽅法
前⾔
代码的可读性、可维护性造成很⼤伤害，进⽽危害到整个软件系统。现在软件开发领域出现了很多新技术、新概念，但 if...else 这种基本的
程序形式并没有发⽣太⼤变化。使⽤好 if...else 不仅对于现在，⽽且对于将来，都是⼗分有意义的。今天我们就来看看如何“⼲掉”代码中
的 if...else，还代码以清爽。
问题⼀：if...else 过多
问题表现
分⽀的情况。另外，if...else 过多通常会伴随着另两个问题：逻辑表达式复杂和 if...else 嵌套过深。对于后两个问题，本⽂将在下⾯两节介
绍。本节先来讨论 if...else 过多的情况。
if (condition1) { } else if (condition2) { } else if (condition3) { } else if (condition4) { } else { }
通常，if...else 过多的⽅法，通常可读性和可扩展性都不好。从软件设计⾓度讲，代码中存在过多的 if...else 往往意味着这段代码违反了违
反单⼀职责原则和开闭原则。因为在实际的项⽬中，需求往往是不断变化的，新需求也层出不穷。所以，软件系统的扩展性是⾮常重要的。
⽽解决 if...else 过多问题的最⼤意义，往往就在于提⾼代码的可扩展性。
如何解决
接下来我们来看如何解决 if...else 过多的问题。下⾯我列出了⼀些解决⽅法。
1. 表驱动
2. 职责链模式
3. 注解驱动
4. 事件驱动
5. 有限状态机
6. Optional
7. Assert
8. 多态
⽅法⼀：表驱动
介绍
对于逻辑表达模式固定的 if...else 代码，可以通过某种映射关系，将逻辑表达式⽤表格的⽅式表⽰；再使⽤表格查的⽅式，到某个输⼊
所对应的处理函数，使⽤这个处理函数进⾏运算。
适⽤场景
逻辑表达模式固定的 if...else
实现与⽰例
if (param.equals(value1)) { doAction1(someParams); } else if (param.equals(value2)) { doAction2(someParams); } else if (param.equals(value3)) { doAction3可重构为
Map<?, Function<?> action> actionMappings = new HashMap<>(); // 这⾥泛型 ? 是为⽅便演⽰，实际可替换为你需要的类型 // When init actionMappings.
上⾯的⽰例使⽤了 Java 8 的 Lambda 和 Functional Interface，这⾥不做讲解。
表的映射关系，可以采⽤集中的⽅式，也可以采⽤分散的⽅式，即每个处理类⾃⾏注册。也可以通过配置⽂件的⽅式表达。总之，形式有很
多。
还有⼀些问题，其中的条件表达式并不像上例中的那样简单，但稍加变换，同样可以应⽤表驱动。下⾯借⽤《编程珠玑》中的⼀个税⾦计算
的例⼦：
if income <= 2200
tax = 0 else if income <= 2700 tax = 0.14 * (income - 2200) else if income <= 3200 tax = 70 + 0.15 * (income - 2700) else if income <= 3700 tax = 145 +
对于上⾯的代码，其实只需将税⾦的计算公式提取出来，将每⼀档的标准提取到⼀个表格，在加上⼀个循环即可。具体重构之后的代码不给
出，⼤家⾃⼰思考。
⽅法⼆：职责链模式
介绍
当 if...else 中的条件表达式灵活多变，⽆法将条件中的数据抽象为表格并⽤统⼀的⽅式进⾏判断时，这时应将对条件的判断权交给每个功能
组件。并⽤链的形式将这些组件串联起来，形成完整的功能。
适⽤场景
条件表达式灵活多变，没有统⼀的形式。
实现与⽰例scala不是内部或外部命令
职责链的模式在开源框架的 Filter、Interceptor 功能的实现中可以见到很多。下⾯看⼀下通⽤的使⽤模式：
重构前：
public void handle(request) { if (handlerA.canHandle(request)) { handlerA.handleRequest(request); } else if (handlerB.canHandle(request)) { handlerB.handleRe 重构后：
public void handle(request) { handlerA.handleRequest(request); } public abstract class Handler { protected Handler next; public abstract void handleRequest
当然，⽰例中的重构前的代码为了表达清楚，做了⼀些类和⽅法的抽取重构。现实中，更多的是平铺式的代码实现。
注：职责链的控制模式
职责链模式在具体实现过程中，会有⼀些不同的形式。从链的调⽤控制⾓度看，可分为外部控制和内部控制两种。
外部控制不灵活，但是减少了实现难度。职责链上某⼀环上的具体实现不⽤考虑对下⼀环的调⽤，因为外部统⼀控制了。但是⼀般的外部控
制也不能实现嵌套调⽤。如果有嵌套调⽤，并且希望由外部控制职责链的调⽤，实现起来会稍微复杂。具体可以参考 Spring Web
Interceptor 机制的实现⽅法。
内部控制就⽐较灵活，可以由具体的实现来决定是否需要调⽤链上的下⼀环。但如果调⽤控制模式是固定的，那这样的实现对于使⽤者来说
是不便的。
设计模式在具体使⽤中会有很多变种，⼤家需要灵活掌握
⽅法三：注解驱动
介绍
通过 Java 注解（或其它语⾔的类似机制）定义执⾏某个⽅法的条件。在程序执⾏时，通过对⽐⼊参与注解中定义的条件是否匹配，再决定是否调⽤此⽅法。具体实现时，可以采⽤表驱动或职责链的⽅式实现。
适⽤场景
适合条件分⽀很多多，对程序扩展性和易⽤性均有较⾼要求的场景。通常是某个系统中经常遇到新需求的核⼼功能。
实现与⽰例
很多框架中都能看到这种模式的使⽤，⽐如常见的 Spring MVC。因为这些框架很常⽤，demo 随处可见，所以这⾥不再上具体的演⽰代码了。
这个模式的重点在于实现。现有的框架都是⽤于实现某⼀特定领域的功能，例如 MVC。故业务系统如采⽤此模式需⾃⾏实现相关核⼼功能。主要会涉及反射、职责链等技术。具体的实现这⾥就不做演⽰了。
⽅法四：事件驱动
介绍
通过关联不同的事件类型和对应的处理机制，来实现复杂的逻辑，同时达到解耦的⽬的。
适⽤场景
从理论⾓度讲，事件驱动可以看做是表驱动的⼀种，但从实践⾓度讲，事件驱动和前⾯提到的表驱动有多处不同。具体来说：
1. 表驱动通常是⼀对⼀的关系；事件驱动通常是⼀对多；
2. 表驱动中，触发和执⾏通常是强依赖；事件驱动中，触发和执⾏是弱依赖
正是上述两者不同，导致了两者适⽤场景的不同。具体来说，事件驱动可⽤于如订单⽀付完成触发库存、物流、积分等功能。
实现与⽰例
实现⽅式上，单机的实践驱动可以使⽤ Guava、Spring 等框架实现。分布式的则⼀般通过各种消息队列⽅式实现。但是因为这⾥主要讨论的是消除 if...else，所以主要是⾯向单机问题域。因为涉及具体技术，所以此模式代码不做演⽰。
⽅法五：有限状态机
介绍
有限状态机通常被称为状态机（⽆限状态机这个概念可以忽略）。先引⽤上的定义：
有限状态机（英语：finite-state machine，缩写：FSM），简称状态机，是表⽰有限个状态以及在这些状态之间的转移和动作等⾏为的数学模型。
其实，状态机也可以看做是表驱动的⼀种，其实就是当前状态和事件两者组合与处理函数的⼀种对应关系。当然，处理成功之后还会有⼀个状态转移处理。
适⽤场景
虽然现在互联⽹后端服务都在强调⽆状态，但这并不意味着不能使⽤状态机这种设计。其实，在很多场景中，如协议栈、订单处理等功能中，状态机有这其天然的优势。因为这些场景中天然存在着状态和状态的流转。
实现与⽰例
实现状态机设计⾸先需要有相应的框架，这个框架需要实现⾄少⼀种状态机定义功能，以及对于的调⽤路由功能。状态机定义可以使⽤DSL 或者注解的⽅式。原理不复杂，掌握了注解、反射等功能的同学应该可以很容易实现。
参考技术：
Apache Mina State Machine
Apache Mina 框架，虽然在 IO 框架领域不及 Netty，但它却提供了⼀个状态机的功能。。有⾃⼰实现状态机功能的同学可以参考其源码。
Spring State Machine
Spring ⼦项⽬众多，其中有个不显⼭不露⽔的状态机框架 —— Spring State Machine 。可以通过 DSL 和注解两种⽅式定义。
上述框架只是起到⼀个参考的作⽤，如果涉及到具体项⽬，需要根据业务特点⾃⾏实现状态机的核⼼功能。
⽅法六：Optional
介绍
Java 代码中的⼀部分 if...else 是由⾮空检查导致的。因此，降低这部分带来的 if...else 也就能降低整体的 if...else 的个数。
Java 从 8 开始引⼊了 Optional 类，⽤于表⽰可能为空的对象。这个类提供了很多⽅法，⽤于相关的操作，可以⽤于消除 if...else。开源框架 Guava 和 Scala 语⾔也提供了类似的功能。
使⽤场景
有较多⽤于⾮空判断的 if...else。
实现与⽰例
传统写法：
String str = "Hello World!";
if (str != null) { System.out.println(str); } else { System.out.println("Null"); }
使⽤ Optional 之后：
Optional<String> 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 类：
Spring 的 Assert 类：
使⽤场景
通常⽤于各种参数校验
扩展：Bean Validation
类似上⼀个⽅法，介绍 Assert 模式顺便介绍⼀个有类似作⽤的技术 —— Bean Validation。Bean Validation 是 Java EE 规范中的⼀
个。Bean Validation 通过在 Java Bean 上⽤注解的⽅式定义验证标准，然后通过框架统⼀进⾏验证。也可以起到了减少 if...else 的作
⽤。
⽅法⼋：多态
介绍
使⽤场景
链接中给出的⽰例⽐较简单，⽆法体现适合使⽤多态消除 if...else 的具体场景。⼀般来说，当⼀个类中的多个⽅法都有类似于⽰例中的
同时，使⽤多态也不是彻底消除 if...else。⽽是将 if...else 合并转移到了对象的创建阶段。在创建阶段的 if..，我们可以使⽤前⾯介绍的⽅法
处理。
⼩结
上⾯这节介绍了 if...else 过多所带来的问题，以及相应的解决⽅法。除了本节介绍的⽅法，还有⼀些其它的⽅法。⽐如，在《重构与模式》
⼀书中就介绍了“⽤ Strategy 替换条件逻辑”、“⽤ State 替换状态改变条件语句”和“⽤ Command 替换条件调度程序”这三个⽅
法。其中的“Command 模式”，其思想同本⽂的“表驱动”⽅法⼤体⼀致。另两种⽅法，因为在《重构与模式》⼀书中已做详细讲解，
这⾥就不再重复。
何时使⽤何种⽅法，取决于⾯对的问题的类型。上⾯介绍的⼀些适⽤场景，只是⼀些建议，更多的需要开发⼈员⾃⼰的思考。
问题⼆：if...else 嵌套过深
问题表现
⾃然也就难以维护。
if (condition1) { action1(); if (condition2) { action2(); if (condition3) { action3(); if (condition4) { action4(); } } } }
如何解决
上⼀节介绍的⽅法也可⽤⽤来解决本节的问题，所以对于上⾯的⽅法，此节不做重复介绍。这⼀节重点⼀些⽅法，这些⽅法并不会降低
1. 抽取⽅法
2. 卫语句
⽅法⼀：抽取⽅法
介绍
适⽤场景
整⼿段。
实现与⽰例
重构前：
public void add(Object element) { if (!readOnly) { int newSize = size + 1; if (newSize > elements.length) { Object[] newElements = new Object[elements.length

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。