Java编程细节-重构-为何 if-else 不是好代码

平时开发中if-else用的多吗？

其实这是个再正常不过的coding习惯，当咱们代码量小的时候用来作条件判断是再简单不过的了。

但对于优秀程序员来讲，这并非好代码，

为啥？

抛开剂量谈毒性都是耍流氓

在使用条件判断语句的地方，若是代码量小，须要判断的场景少的话，

那么没有比 if-else 更合适的语句，好比下面这样

....

if(object.getIndex() > 0) {

//do something

} else {

//do other things

}

那在什么状况下 if-else 才会变差呢？

以上面的代码为例子，当须要判断的状况逐渐增长的时候，上面的代码可能会变的难以维护。

在进阶高级开发的路上，应该逐步培养起这种前瞻意识，

即便在代码还在起步阶段，应该要可以看到未来代码发展的趋势，

好比上面的代码，当状况愈来愈多的时候，if-else可能会发展出许多个分支：

这是彻底可能的，以个人经验来讲就在很多项目上见过这样的代码。

并且代码执行块中的逻辑可能在几回迭代后变的很是复杂，就像下面这样

看到这段代码第一感受就是想杀个小伙伴祭天。

如何重构掉这段代码

对于这种代码咱们重构的目标能够有两个深度，看本身强迫症的严重程度决定

· 继续用 if-else，只达到剥离执行代码块

· 用工厂模式去耦合

对于这两种其实不是非此即彼的关系，而是优化深度不一样。第一种相对比较简单，能够重构成下面这样子

代码清爽了不少，

如今这段代码能够清楚的看出来都处理了哪些状况，条件判断的代码只关注了条件的不一样，

而对于不一样条件的具体处理逻辑咱们剥离到了其余地方，

这样即便写到脑壳迷糊，也不至于说漏了哪一个条件没判断。

进一步优化

在上面的优化以后，如何再用工厂模式来继续重构呢？

从上的代码看的出来，不一样的条件下，执行的逻辑是不一样的，那么能够把这种执行逻辑抽象出来，用多态的概念来定义不一样的执行方式。

完成了这一步以后，就能够把代码块中不一样条件下的方法抽到各个不一样的具体类里面去了，

还能够进一步优化吗？能够的，甚至这里的条件判断均可以不要，咱们能够定义一个工厂来把 new ExecutorWithTag()这件事给包了，

对工厂模式还有印象吗，上面这段代码在我以前的工厂模式一文里出现过，这里能够算是工厂模式的一个实际应用。

在通过这一轮重构以后，咱们以前在一个类里面写的那堆代码已经抽离到多个不一样的类里了，

如今在原来的类里的代码变成怎样了呢，

重构以后各个Executor和主类中的耦合已经降到很低了，

并且代码整洁度提升了不少，以前那个类的一段50+行的代码变成了2行，这就是重构的意义。

喜欢的点点关注，点个赞。

欢迎工做一到五年的Java工程师朋友们加入Java架构开发：878249276,群内提供免费的Java架构学习资料（里面有高可用、高并发、高性能及分布式、Jvm性能调优、Spring源码，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多个知识点的架构资料）合理利用本身每一分每一秒的时间来学习提高本身，不要再用"没有时间“来掩饰本身思想上的懒惰！趁年轻，使劲拼，给将来的本身一个交代！