重构的那些事儿

几天前的一次上线，脑残手抖不小心写了bug，虽然组里的老大没有说什么，但心里面很是难过。同事说我之所以写虫子是因为我讨厌if/else，这个习惯不好。的确，if/else可以帮助我们很方便的写出流程控制代码，简洁明了，这个条件做什么，那个条件做什么，说得很清楚。说真的，我从来不反对if/else，从经验上看，越复杂的业务场景下，代码写的越简单单一，通常越不容易出错。以结果为导向的现代项目管理方式，这是一种很有效实践经验。

同事说的没错，我的确很讨厌if/else。这个习惯很大程度是受Thoughtworks一位咨询师朋友影响，他经常在我耳边唠叨，写代码要干净，要简洁，要灵活多变，不要固守城规，不要动不动就if/else，switch/case。初入it领域，我一直把这句话奉为经典。在以后的学习工作中也时刻提醒自己要让自己的代码尽可能的看起来简洁，不失灵活。不喜欢if/else并不意味着拒绝它，该使用的时候必要使用，比如函数接口入参check，处理异常分支逻辑流程等。通常能不用分支语句，我尽量不会使用，因为我觉得if/else很丑，每每看到if/else代码，总会以挑剔的眼光看待它，想想能不能重构的更好。大多数时候，关于什么好的代码，大家的意见往往分歧很大，每个人都有各自的想法，审查你代码的人可能会选择另一种实现方式，这并不能说明谁对谁错。

OO设计遵循SOLID(单一功能、开闭原则、里氏替换、接口隔离以及依赖反转)原则，使用这个原则去审视if/else，可能会发现很多问题，比如不符合单一原则，它本身就像一团浆糊，融合了各种作料，黏糊糊的很不干净；比如不符合开闭原则，每新增一种场景，就需要修改源文件增加一条分支语句，业务逻辑复杂些若有1000种场景就得有1000个分支流，这种情况下代码不仅仅恶心问题了，效率上也存在很大问题。由此可见，if/else虽然简单方便，但不恰当的使用会给编码代码带来非常痛苦的体验。针对这种恶心的if/else分支，我们当然首先想到的去重构它--在不改变代码外部功能特征的前提下对代码内部逻辑进行调整和优化，但，如何做呢？前段时间在项目中正好遇到一个恶心的if/else例子，想在这篇博客里和大家分享一下去除if/else重构的历程。

if/else的恶瘤

有句话说的好--好文章是改出来，同样，好的代码也肯定是重构出来的，因为没有哪个软件工程师能够拍着胸脯保证在项目之初代码设计这块，就考虑到了所有需求变化可能性的扩展。随着项目的不断成长，业务逻辑变的越来越复杂，代码也开始变的越来越多，原有的设计可能不再满足需求，那么此时必须要重构。就系统整体架构而言，重构可能需要很大的改动，可能在架构流程上需要评审；就功能内代码层次而言，这种重构在我们编码过程中随时可以进行，类似于if/else，swicth/case这种代码的重构也属于这种类型。今天我们要重构的if/else源码如下所示，针对不同的status code，CountRecoder对象会执行不同的set方法，为不同内部属性赋值。

public CountRecoder getCountRecoder(List<CountEntry> countEntries) { CountRecoder countRecoder = new CountRecoder(); for (CountEntry countEntry : countEntries) { if (1 == countEntry.getCode()) { countRecoder.setCountOfFirstStage(countEntry.getCount()); } else if (2 == countEntry.getCode()) { countRecoder.setCountOfSecondStage(countEntry.getCount()); } else if (3 == countEntry.getCode()) { countRecoder.setCountOfThirdtage(countEntry.getCount()); } else if (4 == countEntry.getCode()) { countRecoder.setCountOfForthtage(countEntry.getCount()); } else if (5 == countEntry.getCode()) { countRecoder.setCountOfFirthStage(countEntry.getCount()); } else if (6 == countEntry.getCode()) { countRecoder.setCountOfSixthStage(countEntry.getCount()); } } return countRecoder; }

CountRecoder对象是一个简单的Java Bean，用于保存一天之中六种状态分别对应的数据条目，提供了get和set方法。CountEntry是对应数据库中每种状态的数据条目记录，包含状态code和以及count两个字段, 我们可以使用mybatis实现数据库记录和java对象之间的转换。上面getCountRecoder的方法实现了将list转换为CountRecoder的功能。

看到这段代码，想必已经有很多人要呵呵了，像一坨啥啥啥，长得这么丑，真不知道它"爸妈"怎么想的，怎么敢"生"出来。啥都不说了，直接回炉重构吧。重构是门艺术，Martin flow曾写过一本书《重构改变代码之道》，里面详细的记录了重构的方法论，感兴趣的朋友可以阅读一下。说到重构，通常我们在重构中会遇到一个问题，那就是如何能够保证重构的代码不改变原有的外部功能特征 ？经过TDD训练的朋友应该知道答案，那就是单元测试，重构之前要写单元测试，准确的来说应该是补单元测试，毕竟TDD的核心理念是测试驱动开发。对于今天博客中分享的例子，因为代码逻辑比较简单，所以偷了懒，省却了单元测试的历程。

重构初体验--反射

要重构上面的代码，对设计模式精通的人可以立马可以看出来这是使用策略模式/状态模式的绝佳场景，将策略模式稍微变换，工厂模式应该也是ok的，当然也有些人会选择使用反射。对于这些方法，这里不一一列出，主要想讲一下使用反射和工厂模式如何解决消除if/else问题，那先说反射吧，代码如下所示：

private static Map<Integer, String> methodsMap = new HashMap<>(); static { methodsMap.put(1, "setCountOfFirstStage"); methodsMap.put(2, "setCountOfSecondStage"); methodsMap.put(3, "setCountOfThirdtage"); methodsMap.put(4, "setCountOfForthtage"); methodsMap.put(5, "setCountOfFirthStage"); methodsMap.put(6, "setCountOfSixthStage"); } public CountRecoder getCountRecoderByReflect(List<CountEntry> countEntries) { CountRecoder countRecoder = new CountRecoder(); countEntries.stream().forEach(countEntry -> fillCount(countRecoder, countEntry)); return countRecoder; } private void fillCount(CountRecoder shippingOrderCountDto, CountEntry countEntry) { String name = methodsMap.get(countEntry.getCode()); try { Method declaredMethod = CountRecoder.class.getMethod(name, Integer.class); declaredMethod.invoke(shippingOrderCountDto, countEntry.getCount()); } catch (Exception e) { System.out.println(e); } } 重构初体验--所谓模式