面试官：项目中的if else太多了，该怎么重构？
前言
if else过多的话，一般都是用策略模式来进行重构，策略模式也非常的简单。先定义一个接口，各种处理分支实现这个接口，定义好 条件->处理类的映射关系，然后根据条件找到响应的处理类执行即可，当有新的分支的话，只需要增加一个接口实现类，增加一个条件->映射类的映射关系即可。还是很好容易理解的
介绍
不出意外，这应该是年前最后一次分享，本次来一点实际开发中会用到的小技巧。
比如平时大家是否都会写类似这样的代码：
条件少还好，一旦 else if 过多这里的逻辑将会比较混乱，并很容易出错。
比如这样：
摘自 cim 中的一个客户端命令的判断条件。
刚开始条件较少，也就没管那么多直接写的；现在功能多了导致每次新增一个 else 条件我都得仔细核对，生怕影响之前的逻辑。
这次终于忍无可忍就把他重构了，重构之后这里的结构如下：
最后直接变为两行代码，简洁了许多。
而之前所有的实现逻辑都单独抽取到其他实现类中。
这样每当我需要新增一个 else 逻辑，只需要新增一个类实现同一个接口便可完成。每个处理逻辑都互相独立互不干扰。
实现
按照目前的实现画了一个草图。
整体思路如下：
[*]定义一个 InnerCommand 接口，其中有一个 process 函数交给具体的业务实现。
[*]根据自己的业务，会有多个类实现 InnerCommand 接口；这些实现类都会注册到 Spring Bean 容器中供之后使用。
[*]通过客户端输入命令，从 Spring Bean 容器中获取一个 InnerCommand 实例。
[*]执行最终的 process 函数。
主要想实现的目的就是不在有多个判断条件，只需要根据当前客户端的状态动态的获取 InnerCommand 实例。
从源码上来看最主要的就是 InnerCommandContext 类，他会根据当前客户端命令动态获取 InnerCommand 实例。
[*]第一步是获取所有的 InnerCommand 实例列表。
[*]根据客户端输入的命令从第一步的实例列表中获取类类型。
[*]根据类类型从 Spring 容器中获取具体实例对象。
因此首先第一步需要维护各个命令所对应的类类型。
所以在之前的枚举中就维护了命令和类类型的关系，只需要知道命令就能知道他的类类型。
这样才能满足只需要两行代码就能替换以前复杂的 if else，同时也能灵活扩展。
总结
当然还可以做的更灵活一些，比如都不需要显式的维护命令和类类型的对应关系。
只需要在应用启动时扫描所有实现了 InnerCommand 接口的类即可，在 cicada 中有类似实现，感兴趣的可以自行查看。
这样一些小技巧希望对你有所帮助。
github地址：https://github.com/crossoverJie/cim
作者：crossoverJie
链接：https://juejin.im/post/5c5172d15188256a2334a15d 我觉得重构以后，可阅读性变低了，而且这里的ifelse只是转移到了其他地方，毕竟这种映射关系是必须存在的，只是在哪里存在而已 这种做法既降低了可读性也降低了效率，犯了为了模式而模式的错误。你看过设计模式的教材应该就知道，设计模式虽然能让一定程度让代码的可扩展性和可维护性提高，但同时会让类的数目大幅增加，代码变得难以理解，需要根据实际需求使用设计模式，而不是为了模式而模式 if else结构简单，性能好，如果分支太多可以用表来处理，套用设计模式多出一堆乱七八糟的类或接口不说，还要用到反射，性能差得远了。 为什么一定要重构？ 为什么要重构，重构出了问题谁负责 不知道重构之后新写的类和接口又有多少代码？真的少了吗？ 反向if，直接return 改修项目 有一个前提非常重要，那就是不要影响原先的逻辑。你加一堆类，原先的那些分支逻辑要全部重新测试了。测试的人非找你拼命不可。重构看上去很美好，其实需要付出大量时间，金钱。 [酷拽]还是觉得if else好用，其他的都是些花里胡哨的东西
页:
[1]
2