你还在 if...else？代码这样写才好看！

前言

if...else 是全部高级编程语言都有的必备功能。但现实中的代码每每存在着过多的 if...else。虽然 if...else 是必须的，但滥用 if...else 会对代码的可读性、可维护性形成很大伤害，进而危害到整个软件系统。如今软件开发领域出现了不少新技术、新概念，但 if...else 这种基本的程序形式并无发生太大变化。使用好 if...else 不只对于如今，并且对于未来，都是十分有意义的。今天咱们就来看看如何“干掉”代码中的 if...else，还代码以清爽。html

问题一：if…else 过多

问题表现

if...else 过多的代码能够抽象为下面这段代码。其中只列出5个逻辑分支，但实际工做中，能见到一个方法包含10个、20个甚至更多的逻辑分支的状况。另外，if...else 过多一般会伴随着另两个问题：逻辑表达式复杂和 if...else 嵌套过深。对于后两个问题，本文将在下面两节介绍。本节先来讨论 if...else 过多的状况。java

if (condition1) {

} else if (condition2) {

} else if (condition3) {

} else if (condition4) {

} else {

}

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

如何解决

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

1. 表驱动
1. 职责链模式
1. 注解驱动
1. 事件驱动
1. 有限状态机
1. Optional
1. Assert
1. 多态

方法一：表驱动

介绍

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

适用场景

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

实现与示例

if (param.equals(value1)) {
    doAction1(someParams);
} else if (param.equals(value2)) {
    doAction2(someParams);
} else if (param.equals(value3)) {
    doAction3(someParams);
}
// ...

可重构为编程

Map<?, Function<?> action> actionMappings = new HashMap<>(); // 这里泛型 ? 是为方便演示，实际可替换为你须要的类型

// When init
actionMappings.put(value1, (someParams) -> { doAction1(someParams)});
actionMappings.put(value2, (someParams) -> { doAction2(someParams)});
actionMappings.put(value3, (someParams) -> { doAction3(someParams)});

// 省略 null 判断
actionMappings.get(param).apply(someParams);

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

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

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

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 + 0.16 * (income - 3200)
......
else
  tax = 53090 + 0.7 * (income - 102200)

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

方法二：职责链模式

介绍

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

适用场景

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

实现与示例

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

重构前：

public void handle(request) {
    if (handlerA.canHandle(request)) {
        handlerA.handleRequest(request);
    } else if (handlerB.canHandle(request)) {
        handlerB.handleRequest(request);
    } else if (handlerC.canHandle(request)) {
        handlerC.handleRequest(request);
    }
}

重构后：

public void handle(request) {
  handlerA.handleRequest(request);
}

public abstract class Handler {
  protected Handler next;
  public abstract void handleRequest(Request request);
  public void setNext(Handler next) { this.next = next; }
}

public class HandlerA extends Handler {
  public void handleRequest(Request request) {
    if (canHandle(request)) doHandle(request);
    else if (next != null) next.handleRequest(request);
  }
}

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

注：职责链的控制模式

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

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

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

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

方法三：注解驱动

介绍

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

适用场景

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

实现与示例

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

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

方法四：事件驱动

介绍

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

适用场景

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

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

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

实现与示例

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

方法五：有限状态机

介绍

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

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

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

适用场景

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

实现与示例

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

参考技术：

Apache Mina State Machine Apache Mina 框架，虽然在 IO 框架领域不及 Netty，但它却提供了一个状态机的功能。https://mina.apache.org/mina-project/userguide/ch14-state-machine/ch14-state-machine.html。有本身实现状态机功能的同窗能够参考其源码。
Spring State Machine Spring 子项目众多，其中有个不显山不露水的状态机框架 —— Spring State Machine https://projects.spring.io/spring-statemachine/。能够经过 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 以后：

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 的做用。在代码重构这本书中，对此也有介绍：

https://refactoring.com/catalog/replaceConditionalWithPolymorphism.html

使用场景

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

if (condition1) {
    action1();
    if (condition2) {
        action2();
        if (condition3) {
            action3();
            if (condition4) {
                action4();
            }
        }
    }
}

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

如何解决

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

抽取方法
卫语句

方法一：抽取方法

介绍

抽取方法是代码重构的一种手段。定义很容易理解，就是将一段代码抽取出来，放入另外一个单独定义的方法。借

用 https://refactoring.com/catalog/extractMethod.html 中的定义：

适用场景

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

实现与示例

重构前：

public void add(Object element) {
  if (!readOnly) {
    int newSize = size + 1;
    if (newSize > elements.length) {
      Object[] newElements = new Object[elements.length + 10];
      for (int i = 0; i < size; i++) {
        newElements[i] = elements[i];
      }

      elements = newElements
    }
    elements[size++] = element;
  }
}

重构后：

public void add(Object element) {
  if (readOnly) {
    return;
  }

  if (overCapacity()) {
    grow();
  }

  addElement(element);
}

方法二：卫语句

介绍

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

double getPayAmount() {
    double result;
    if (_isDead) result = deadAmount();
    else {
        if (_isSeparated) result = separatedAmount();
        else {
            if (_isRetired) result = retiredAmount();
            else result = normalPayAmount();
        };
    }
    return result;
}

重构以后

double getPayAmount() {
    if (_isDead) return deadAmount();
    if (_isSeparated) return separatedAmount();
    if (_isRetired) return retiredAmount();
    return normalPayAmount();
}

使用场景

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

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

问题表现

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

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

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

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

如何解决

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

总结

本文一个介绍了10种（算上扩展有12种）用于消除、简化 if...else 的方法。还有一些方法，如经过策略模式、状态模式等手段消除 if...else 在《重构与模式》一书中也有介绍。

正如前言所说，if...else 是代码中的重要组成部分，可是过分、没必要要地使用 if...else，会对代码的可读性、可扩展性形成负面影响，进而影响到整个软件系统。

“干掉”if...else 的能力高低反映的是程序员对软件重构、设计模式、面向对象设计、架构模式、数据结构等多方面技术的综合运用能力，反映的是程序员的内功。要合理使用 if...else，不能没有设计，也不能过分设计。这些对技术的综合、合理地运用都须要程序员在工做中不断的摸索总结。

做者：艾瑞克·邵来源：www.cnblogs.com/eric-shao/p/10115577.html

欢迎关注公众号【码农开花】一块儿学习成长我会一直分享Java干货，也会分享免费的学习资料课程和面试宝典回复：【计算机】【设计模式】【002】有惊喜哦

你还在 if...else？代码这样写才好看！

前言

问题一：if…else 过多

问题表现

如何解决

方法一：表驱动

介绍

适用场景

实现与示例

方法二：职责链模式

介绍

适用场景

实现与示例

注：职责链的控制模式

方法三：注解驱动

介绍

适用场景

实现与示例

方法四：事件驱动

介绍

适用场景

实现与示例

方法五：有限状态机

介绍

适用场景

实现与示例

方法六：Optional

介绍

使用场景

实现与示例

扩展：Kotlin Null Safety

方法七：Assert 模式

介绍

使用场景

扩展：Bean Validation

方法八：多态

介绍

使用场景

小结

问题二：if…else 嵌套过深

问题表现

如何解决

方法一：抽取方法

** **

介绍

适用场景

实现与示例

方法二：卫语句

介绍

使用场景

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

问题表现

如何解决

总结