这才是“干掉 if else”的正确姿势！

姿势！"/>

这才是“干掉 if else”的正确姿势！

先说一点，我干不掉 if else，代码中必然会存在 if else。因为代码本身就是由顺序、分支、循环构成的(Java 中没有 goto)。分支是业务逻辑中天然存在的，所以，我给“干掉 if else”打上了引号。

那既然干不掉 if else，就只能仍有代码杂乱无章吗？

答案是否定的，今天我就从我个人工作十几年的角度告诉你，“干掉 if else”最正确的姿势。

说实话，网上的那些使用责任链模式，有限状态机，事件驱动等方式我都不推荐。因为，太麻烦了！我的原则是，写代码能不麻烦就不麻烦，能有多简单就多简单，别让代码“臃肿”就行！

下面先说我的第一种优化方式，针对空异常、数值判断等情况的。示例代码如下所示：

你看，如果我的方法中，有十几个属性需要判断，是不是就需要十几个 if else 去处理？太复杂了，太臃肿了，if else 看的我头都大了。那么该怎么办呢？

将上面的代码改成使用 Assert 去处理。这样，方法中的代码是不是就好看多了？把简洁养成个人习惯！

然后抛出的异常该怎么处理呢？ControllerAdvice，全局异常处理。拦截所有异常，自己定义状态码，返回给各个接口！

第二种，优化“if else”的示例代码如下所示：

这段代码带上 else 分支也没关系，照样能优化。还有类似下面的代码，虽然有注释，但是还是太复杂化了。

而我的“去掉 if else”或者说简化 if else 的方案如下：

虽然还存在“if else”，但是看起来逻辑更清晰一些了。分支更少了，代码更简洁了！

有可能你看不出什么效果，但是当你遇到嵌套十几个 if else 的时候，你就明白了我这样写的好处了。十几个 if else 可能按照我这样写了之后，就只剩几个 if else 了。就是老板给你再派一堆新手，也能快速熟悉业务逻辑了。

我不推荐责任链模式不是因为它不好，而是多数情况下有点本末倒置。它有它的使用场景，但是在本文我列举的这些案例它不合适！

以上就是我的断言 + 断路干掉“if else”的经验实战了，虽然不华丽，但毕竟实用！本文已录制成了一个小视频，放在 b 站上，地址：。我小试牛刀，2020 希望能给大家录制一些优质视频，一起精进！