如何解决代码中if…else 过多的问题

前言

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 过多的状况。

若是想学习Java工程化、高性能及分布式、深刻浅出。微服务、Spring，MyBatis，Netty源码分析的朋友能够加个人Java高级交流：854630135，群里有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给你们。

1 if (condition1) {
 2 
 3 } else if (condition2) {
 4 
 5 } else if (condition3) {
 6 
 7 } else if (condition4) {
 8 
 9 } else {
10 
11 }

一般，if...else 过多的方法，一般可读性和可扩展性都很差。从软件设计角度讲，代码中存在过多的 if...else 每每意味着这段代码违反了违反单一职责原则和开闭原则。由于在实际的项目中，需求每每是不断变化的，新需求也层出不穷。因此，软件系统的扩展性是很是重要的。而解决 if...else 过多问题的最大意义，每每就在于提升代码的可扩展性。

如何解决

接下来咱们来看如何解决 if...else 过多的问题。下面我列出了一些解决方法。

1. 表驱动
2. 职责链模式
3. 注解驱动
4. 事件驱动
5. 有限状态机
6. Optional
7. Assert
8. 多态

方法一：表驱动

介绍

对于逻辑表达模式固定的 if...else 代码，能够经过某种映射关系，将逻辑表达式用表格的方式表示；再使用表格查找的方式，找到某个输入所对应的处理函数，使用这个处理函数进行运算。

适用场景

逻辑表达模式固定的 if...else

实现与示例

1 if (param.equals(value1)) {
2 doAction1(someParams);
3 } else if (param.equals(value2)) {
4 doAction2(someParams);
5 } else if (param.equals(value3)) {
6 doAction3(someParams);
7 }
8 // ...

可重构为

1 Map<?, Function<?> action> actionMappings = new HashMap<>(); // 这里泛型 ? 是为方便演示，实际可替换为你须要的类型
2 
3 // When init
4 actionMappings.put(value1, (someParams) -> { doAction1(someParams)});
5 actionMappings.put(value2, (someParams) -> { doAction2(someParams)});
6 actionMappings.put(value3, (someParams) -> { doAction3(someParams)});
7 
8 // 省略 null 判断
9 actionMappings.get(param).apply(someParams);

上面的示例使用了 Java 8 的 Lambda 和 Functional Interface，这里不作讲解。

表的映射关系，能够采用集中的方式，也能够采用分散的方式，即每一个处理类自行注册。也能够经过配置文件的方式表达。总之，形式有不少。

还有一些问题，其中的条件表达式并不像上例中的那样简单，但稍加变换，一样能够应用表驱动。下面借用《编程珠玑》中的一个税金计算的例子：

1 if income <= 2200
 2 tax = 0
 3 else if income <= 2700
 4 tax = 0.14 * (income - 2200)
 5 else if income <= 3200
 6 tax = 70 + 0.15 * (income - 2700)
 7 else if income <= 3700
 8 tax = 145 + 0.16 * (income - 3200)
 9 ......
10 else
11 tax = 53090 + 0.7 * (income - 102200)

对于上面的代码，其实只需将税金的计算公式提取出来，将每一档的标准提取到一个表格，在加上一个循环便可。具体重构以后的代码不给出，你们本身思考。

方法二：职责链模式

介绍

当 if...else 中的条件表达式灵活多变，没法将条件中的数据抽象为表格并用统一的方式进行判断时，这时应将对条件的判断权交给每一个功能组件。并用链的形式将这些组件串联起来，造成完整的功能。

适用场景

条件表达式灵活多变，没有统一的形式。

实现与示例

职责链的模式在开源框架的 Filter、Interceptor 功能的实现中能够见到不少。下面看一下通用的使用模式：

重构前：

1 public void handle(request) {
2 if (handlerA.canHandle(request)) {
3 handlerA.handleRequest(request);
4 } else if (handlerB.canHandle(request)) {
5 handlerB.handleRequest(request);
6 } else if (handlerC.canHandle(request)) {
7 handlerC.handleRequest(request);
8 }
9 }

重构后：

若是想学习Java工程化、高性能及分布式、深刻浅出。微服务、Spring，MyBatis，Netty源码分析的朋友能够加个人Java高级交流：854630135，群里有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给你们。

1 public void handle(request) {
 2 handlerA.handleRequest(request);
 3 }
 4 
 5 public abstract class Handler {
 6 protected Handler next;
 7 public abstract void handleRequest(Request request);
 8 public void setNext(Handler next) { this.next = next; }
 9 }
10 
11 public class HandlerA extends Handler {
12 public void handleRequest(Request request) {
13 if (canHandle(request)) doHandle(request);
14 else if (next != null) next.handleRequest(request);
15 }
16 }

固然，示例中的重构前的代码为了表达清楚，作了一些类和方法的抽取重构。现实中，更多的是平铺式的代码实现。

注：职责链的控制模式

职责链模式在具体实现过程当中，会有一些不一样的形式。从链的调用控制角度看，可分为外部控制和内部控制两种。

外部控制不灵活，可是减小了实现难度。职责链上某一环上的具体实现不用考虑对下一环的调用，由于外部统一控制了。可是通常的外部控制也不能实现嵌套调用。若是有嵌套调用，而且但愿由外部控制职责链的调用，实现起来会稍微复杂。

内部控制就比较灵活，能够由具体的实现来决定是否须要调用链上的下一环。但若是调用控制模式是固定的，那这样的实现对于使用者来讲是不便的。

设计模式在具体使用中会有不少变种，你们须要灵活掌握

方法三：注解驱动

介绍

经过 Java 注解（或其它语言的相似机制）定义执行某个方法的条件。在程序执行时，经过对比入参与注解中定义的条件是否匹配，再决定是否调用此方法。具体实现时，能够采用表驱动或职责链的方式实现。

适用场景

适合条件分支不少多，对程序扩展性和易用性均有较高要求的场景。一般是某个系统中常常遇到新需求的核心功能。

实现与示例

不少框架中都能看到这种模式的使用，好比常见的 Spring MVC。由于这些框架很经常使用，demo 随处可见，因此这里再也不上具体的演示代码了。

这个模式的重点在于实现。现有的框架都是用于实现某一特定领域的功能，例如 MVC。故业务系统如采用此模式需自行实现相关核心功能。主要会涉及反射、职责链等技术。具体的实现这里就不作演示了。

方法四：事件驱动

介绍

经过关联不一样的事件类型和对应的处理机制，来实现复杂的逻辑，同时达到解耦的目的。

适用场景

从理论角度讲，事件驱动能够看作是表驱动的一种，但从实践角度讲，事件驱动和前面提到的表驱动有多处不一样。具体来讲：

1. 表驱动一般是一对一的关系；事件驱动一般是一对多；
2. 表驱动中，触发和执行一般是强依赖；事件驱动中，触发和执行是弱依赖

正是上述二者不一样，致使了二者适用场景的不一样。具体来讲，事件驱动可用于如订单支付完成触发库存、物流、积分等功能。

实现与示例

实现方式上，单机的实践驱动可使用 Guava、Spring 等框架实现。分布式的则通常经过各类消息队列方式实现。可是由于这里主要讨论的是消除 if...else，因此主要是面向单机问题域。由于涉及具体技术，因此此模式代码不作演示。

方法五：有限状态机

介绍

有限状态机一般被称为状态机（无限状态机这个概念能够忽略）。先引用维基百科上的定义：

有限状态机（英语：finite-state machine，缩写：FSM），简称状态机，是表示有限个状态以及在这些状态之间的转移和动做等行为的数学模型。

其实，状态机也能够看作是表驱动的一种，其实就是当前状态和事件二者组合与处理函数的一种对应关系。固然，处理成功以后还会有一个状态转移处理。

适用场景

虽然如今互联网后端服务都在强调无状态，但这并不意味着不能使用状态机这种设计。其实，在不少场景中，如协议栈、订单处理等功能中，状态机有这其自然的优点。由于这些场景中自然存在着状态和状态的流转。

实现与示例

实现状态机设计首先须要有相应的框架，这个框架须要实现至少一种状态机定义功能，以及对于的调用路由功能。状态机定义可使用 DSL 或者注解的方式。原理不复杂，掌握了注解、反射等功能的同窗应该能够很容易实现。

方法六：Optional

介绍

Java 代码中的一部分 if...else 是由非空检查致使的。所以，下降这部分带来的 if...else 也就能下降总体的 if...else 的个数。

Java 从 8 开始引入了 Optional 类，用于表示可能为空的对象。这个类提供了不少方法，用于相关的操做，能够用于消除 if...else。开源框架 Guava 和 Scala 语言也提供了相似的功能。

使用场景

有较多用于非空判断的 if...else。

实现与示例

传统写法：

1 String str = "Hello World!";
2 if (str != null) {
3 System.out.println(str);
4 } else {
5 System.out.println("Null");
6 }

使用 Optional 以后：

1 Optional<String> strOptional = Optional.of("Hello World!");
2 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 的做用。

使用场景

连接中给出的示例比较简单，没法体现适合使用多态消除 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 之间嵌套的很深，也很复杂，致使代码可读性不好，天然也就难以维护。

1 if (condition1) {
 2 action1();
 3 if (condition2) {
 4 action2();
 5 if (condition3) {
 6 action3();
 7 if (condition4) {
 8 action4();
 9 }
10 }
11 }
12 }

if...else 嵌套过深会严重地影响代码的可读性。固然，也会有上一节提到的两个问题。

如何解决

上一节介绍的方法也可用用来解决本节的问题，因此对于上面的方法，此节不作重复介绍。这一节重点一些方法，这些方法并不会下降 if...else 的个数，可是会提升代码的可读性：

1. 抽取方法
2. 卫语句

方法一：抽取方法

介绍

抽取方法是代码重构的一种手段。定义很容易理解，就是将一段代码抽取出来，放入另外一个单独定义的方法。借用 https://refactoring.com/catalog/extractMethod.html 中的定义：

适用场景

if...else 嵌套严重的代码，一般可读性不好。故在进行大型重构前，需先进行小幅调整，提升其代码可读性。抽取方法即是最经常使用的一种调整手段。

实现与示例

重构前：

1 public void add(Object element) {
 2 if (!readOnly) {
 3 int newSize = size + 1;
 4 if (newSize > elements.length) {
 5 Object[] newElements = new Object[elements.length + 10];
 6 for (int i = 0; i < size; i++) {
 7 newElements[i] = elements[i];
 8 }
 9 
10 elements = newElements
11 }
12 elements[size++] = element;
13 }
14 }

重构后：

1 public void add(Object element) {
 2 if (readOnly) {
 3 return;
 4 }
 5 
 6 if (overCapacity()) {
 7 grow();
 8 }
 9 
10 addElement(element);
11 }

方法二：卫语句

介绍

在代码重构中，有一个方法被称为“使用卫语句替代嵌套条件语句”https://refactoring.com/catalog/replaceNestedConditionalWithGuardClauses.html。直接看代码：

1 double getPayAmount() {
 2 double result;
 3 if (_isDead) result = deadAmount();
 4 else {
 5 if (_isSeparated) result = separatedAmount();
 6 else {
 7 if (_isRetired) result = retiredAmount();
 8 else result = normalPayAmount();
 9 };
10 }
11 return result;
12 }

重构以后

1 double getPayAmount() {
2 if (_isDead) return deadAmount();
3 if (_isSeparated) return separatedAmount();
4 if (_isRetired) return retiredAmount();
5 return normalPayAmount();
6 }

使用场景

当看到一个方法中，某一层代码块都被一个 if...else 完整控制时，一般能够采用卫语句。

问题三：if...else 表达式过于复杂

问题表现

if...else 所致使的第三个问题来自过于复杂的条件表达式。下面给个简单的例子，当 condition 一、二、三、4 分别为 true、false，请你们排列组合一下下面表达式的结果。

1 if ((condition1 && condition2 ) || ((condition2 || condition3) && condition4)) {
2 
3 }

我想没人愿意干上面的事情。关键是，这一大坨表达式的含义是什么？关键便在于，当不知道表达式的含义时，没人愿意推断它的结果。

因此，表达式复杂，并不必定是错。可是表达式难以让人理解就很差了。

如何解决

对于 if...else 表达式复杂的问题，主要用代码重构中的抽取方法、移动方法等手段解决。由于这些方法在《代码重构》一书中都有介绍，因此这里再也不重复。

欢迎工做一到八年的Java工程师朋友们加入Java高级交流：854630135

本群提供免费的学习指导 架构资料 以及免费的解答

不懂得问题均可以在本群提出来 以后还会有直播平台和讲师直接交流噢