先说一点,我干不掉 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 站上,地址:https://www.bilibili.com/video/av82196871我小试牛刀,2020 希望能给大家录制一些优质视频,一起精进!