为什么if-else会影响我的代码的复杂度

关于if-else的争议

我之前写了一篇文章《我用规则引擎消除if语句，提高了代码的可扩展性》，这篇文章我想阐述的观点是复杂的if语句可能会影响代码的阅读和代码的扩展性，会将非业务的条件逻辑与业务逻辑混合在一起。时间长了代码会越来越臃肿，因此这种情况下我推荐使用一些设计模式例如策略模式，责任链模式等去优化if语句带来的问题，文中我发现使用规则引擎也能实现类似效果，因此介绍了怎么使用规则引擎Easy Rules去取代if语句。

if-else增加了代码复杂度

侧写师，公众号：Lvshen的技术小屋我用规则引擎实现了消除if语句

文章发布后，有很大一部分读者认为只用设计模式会增加代码阅读性，还是会觉得if-else好，就算if写得再复杂，也要使用if-else。

其实这里使用设计模式并不复杂，主要就是

“

1. 将条件抽出，形成条件类，

2. 然后将条件存入集合中，

3. 遍历这个集合即可

”

如果我们需要修改条件，只需要修改条件类，即步骤1即可。2、3步骤的代码我们不需要去管理。

其实规则引擎很强大，可以有更复杂的用途，我这里使用规则引擎其实和策略模式差不多，有人会考虑第三方API有风险，这个就需要团队判断了。不过规则引擎已经算是比较成熟的框架了，如果对这方面担忧的建议使用策略模式。

用图来表示就是上面这个样子，是不是有点像服务注册。

读者大部分不赞成使用设计模式的原因是：if-else能看懂，设计模式可能会看不懂，觉得这是一个没有必要的纠结。

当然也有赞同我的观点的：

统计了下，有八成读者评论是反对用其他方法代替if-else的😔。所以我还是想写篇文章表达下我的观点。

关于if-else我的观点

其实我觉得大部分开发反对用其他方法代替if-else可能是编写的项目迭代变化不多，本身业务并不那么复杂，用if-else反而更简单。

这里我要阐明我的一个观点：

“

我的观点并不是说，我们在编码时不能使用if-else，而是说我们不应该简陋地用if-else去实现业务的分支流程，因为这样随意的代码堆砌很容易堆出一座座"屎山"。

”

当我们存在不同的业务逻辑时，我们通常习惯使用if-else来实现这些不同的逻辑，时间长了，代码就会难以维护。我相信大部分人写过下面类似的代码。

屎山代码雏形

上面的代码（基于实际项目的伪代码），大家看了后有什么感想。如果我们需要修改上面的条件逻辑，我相信编码者本人都会被这样的代码绕晕，更不用说后面接手的开发了。

关于对复杂的if-else可能产生的问题，大家可以看看这篇文章文章：

“

[面对复杂业务，if-else coder 如何升级？-阿里云开发者社区 (aliyun.com)]-(https://developer.aliyun.com/article/775900)

”

文章作者阿里巴巴高级技术专家。

实际工作中，能见到一个方法包含10个、20个甚至更多的逻辑分支的情况。

if (condition1) {
 do1;
} else if (condition2) { 
 do2;
} else if (condition3) { 
 do3;
} else if (condition4) { 
 do4;
} else { 
 do5;
}

if-else 过多的方法，通常可读性和可扩展性都不好。从软件设计角度讲，代码中存在过多的 if-else 往往意味着这段代码违反了违反单一职责原则和开闭原则。因为在实际的项目中，需求往往是不断变化的，新需求也层出不穷。所以，软件系统的扩展性是非常重要的。而解决 if-else 过多问题的最大意义，往往就在于提高代码的可扩展性。

有的代码 if-else 不仅个数多，而且 if-else 之间嵌套的很深，也很复杂，导致代码可读性很差，自然也就难以维护。

if (condition1) { 
   do1(); 
   if (condition2) { 
      do2(); 
      if (condition3) { 
         do3(); 
         if (condition4) { 
             do4(); 
         } 
      } 
   } 
}

这种嵌套方式看了可能会头晕，我一般会将每个if都能写到最外层。

if (condition1) {
   do1();
}
if (condition1 && condition2) {
   do2();
}
if (condition1 && condition2 && condition3) {
   do3();
}
if (condition1 && condition2 && condition3 && condition4) {
   do4();
}

其实if-else 以及类似的switch控制语句，本质上是一种硬编码行为，这种硬编码问题在于当需求发生改变时，需要到处去修改，很容易遗漏和出错。即使在代码还在起步阶段，我们也要能够看到将来代码发展的趋势。

真的不要觉得设计代码是一件费时费力的事情，到了多次项目迭代后，我们会发现好的设计可以提高工作效率和代码质量。

关于if-else的建议

一般来说，如果if-else不影响阅读和业务的扩展需求，我们可以不考虑其他编码方式，毕竟if-else就是最简洁的了。如果随着版本迭代，if-else越来越多，堆积的代码越来越臃肿，已经影响代码阅读和功能扩展。我们就可以考虑怎么优化if-else了。

一些经验老到的开发可能一开始就会预料到这种场景，在编码初期就开始思考如何设计代码了。作为一般开发者来说，我们不必如此，我们可以在版本多次迭代后，当问题显露出来时，思考这些问题也是可以的。很多项目其实会有重构环节，我们在重构时思考我觉得也不晚。

关于减少复杂if-else的方法，推荐大家看看这些文章：

“

[if-else语句太多了？我用设计模式消除了if-else]-(https://www.toutiao.com/item/6883639027053003271/)

[如何用枚举消除if/else?-枚举高阶用法]-(https://www.toutiao.com/item/6867677967380644365/)

[设计模式12之策略模式]-(https://www.toutiao.com/item/6887717944063689227/)

”

如果这篇文章对你有帮助，欢迎点赞和转发。