策略枚举：消除在项目里大批量使用 if-else 的正确姿势
文/朱季谦
想起刚开始接触 JAVA 面向对象编程时，若遇到大量流程判断语句，几乎满屏都是 if-else 语句，多得让自己都忘了哪里是头，哪里是尾，但是，纵然满屏是 if-else，但彼时也没有觉得多别扭。等到编程能力渐渐提升之后，再回过头去看曾经写过的满屏 if-else 时，脑海里只有一个画面，全都是翔.....
可能初学者都会忽略掉一点，其实 if-else 是一种面向过程的实现。
那么，如何避免在面向对象编程里大量使用 if-else 呢？
网络上有很多解决思路，有工厂模式、策略模式、甚至是规则引擎（这个太重了吧）......
这些，都有一个共同的缺点，使用起来还是过于繁重了。虽说避免出现过多的 if-else，但是，却会增加很多额外的类，我总觉得，很不实用，只能当做某种模式的学习即可。
可以替换大量的 if-else 语句，且具备较好的可读性与扩展性，同时能显得轻量化，我比较推荐使用策略枚举来消除 if-else。
如何使用呢，下面先从一个业务案例开始说起下——
假如有这样一个需求，需实现一周七天内分别知道要做事情的备忘功能，这里面就会涉及到一个流程判断，你可能会立马想到用 if-else，那么，可能是会这样实现——
这种代码，在业务逻辑里，少量还好，若是几百个判断呢，可能整块业务逻辑里都是满屏 if-else,既不优雅也显得很少冗余。
这时，就可以考虑使用策略枚举形式来替换这堆面向过程的 if-else 实现了。
首先，先定义一个 getToDo()调用方法，假如传进的是“星期一”，即参数"Monday"。
在 getToDo()方法里，通过 DayEnum.valueOf("Monday")可获取到一个 DayEnum 枚举元素，这里得到的是 Monday。
接下来，执行 checkDay.day(DayEnum.valueOf("Monday"))，会进入到 day（）方法中，这里，通过 dayEnum.toDo()做了一个策略匹配时。注意一点，DayEnum.valueOf("Monday")得到的是枚举中的 Monday，这样，实质上就是执行了 Monday.toDo()，也就是说，会执行 Monday 里的 toDo()——
上面的执行过程为什么会是这样子呢？只有进入到 DayEnum 枚举当中，才知道是怎么回事了——(话外音：我第一次接触策略模式时，猛地一惊，原来枚举还可以这样玩)
在 DayEnum 枚举属性当中，定义了一个实现了 toDo()抽象方法——
在每个枚举元素当中，都重写了该 toDo()抽象方法。这样，当传参 DayEnum.valueOf("Monday")流转到 dayEnum.toDo()时，实质上是去 DayEnum 枚举里找到对应 Monday 定义的枚举元素，然后执行其内部重写的 toDo()方法。用 if-esle 形式表示，就类似"Monday".equals(day)匹配为 true 时，可得到其内部东西。
总结一下，策略枚举就是枚举当中使用了策略模式，所谓的策略模式，即给你一把钥匙，按照某种约定的方式，可以立马被指引找到可以打开的门。例如，我给你的钥匙叫“Monday”，那么，就可以通过约定方式 dayEnum.toDo()，立马找到枚举里的 Monday 大门，然后进到门里，去做想做的事 toDo()，其中，每扇门后的房间都有不同的功能，但它们都有一个相同抽象功能——toDo()，即各房间共同地方都是可以用来做一些事情的功能，但具体可以什么事情，就各有不同了。在本文的案例里，每扇大门里的 toDo()，根据不同策略模式可得到不同字符串返回，例如，"今天上英语课"、"今天上语文课"，等等。
可见，把流程判断抽取到策略枚举当中，还可以把一堆判断解耦出来，避免在业务代码逻辑里呈现一大片密密麻麻冗余的 if-else。
这里，会出现一种情况，即，假如有多个重复共同样功能的判断话，例如，在 if-else 里，是这样——
那么，在策略枚举下应该如何使用从而避免代码冗余呢？
可以参考一下以下思路，设置一个内部策略枚举，将有相同功能的外部引用指向同一个内部枚举元素，这样即可实现调用重复功能了——
若要扩展其判断流程，只需要直接在枚举增加一个属性和内部 toDo（实现），就可以增加新的判断流程了，而外部，仍旧用同一个入口 dayEnum.toDo()即可。
可能，会有这样一个疑问：为什么在枚举里定义一个抽象方法，会在各个枚举元素里实现呢？
这功能就类似子类继承父类的做法了。DayEnum 类似一个父类，DayEnum 枚举里的元素就相当是其子类。当父类里定义了抽象方法 toDo（），其继承的子类就会默认实现 toDo()方法，这样，就会出现枚举里可以这样的写法：
我很喜欢在大批量 if-else 里使用策略枚举来消除替换，总而言之，使用策略枚举可以很灵活处理各种复杂判断，且可读性与扩展性都比较好，它更像是函数式编程，即传进一个参数，就可以得到对应模式下返回的数值。
若 Java 里业务逻辑中大批量使用 if-else，则是面向过程了，因为业务逻辑里的 if-else 是从上往下一个 if 接一个 if 判断下去的，在各个 if 上打个断点，debug 下去，就明白它其实是面向过程的。
由此可知，若项目里有大量的 if-else 话，着实是一件很影响性能的事情。
版权声明: 本文为 InfoQ 作者【朱季谦】的原创文章。
原文链接:【http://xie.infoq.cn/article/9369635b15f3f79981042d218】。文章转载请联系作者。
一个以编程为生的荒诞小说家 2018.06.29 加入
汤圆创作APP签约作者； 简书优秀认证作者； Java后端程序员； PMP认证人员； 学生时代著有《黑色玫瑰》一书已上架微信读书APP；
评论