侧边栏壁纸
  • 累计撰写 123 篇文章
  • 累计创建 48 个标签
  • 累计收到 0 条评论

目 录CONTENT

文章目录

优化代码中大量的ifelse,你有什么方案?

田小晖
2020-06-30 / 0 评论 / 0 点赞 / 399 阅读 / 0 字 / 正在检测是否收录...

面试官:优化代码中大量的if/else,你有什么方案?

一个快速迭代的项目,时间久了之后,代码中可能会充斥着大量的if/else,嵌套6、7层,一个函数几百行,简!直!看!死!人!

3b6f00c3776b49ecb0d0de58d4ae21ef

这个无限循环嵌套,只是总循环的一部分。。。我已经绕晕在黄桷湾立交

仔细数了数,一共有 11 层的嵌套!!!接手这种项目的同学,内心应该是绝望的。

336b1fdab1eb4626bbcc9ec67c112b16

出现这种情况的原因很多

  • 设计不够完善
  • 需求考虑不完全
  • 开发人员变动

但最为致命的是“懒”

85fe07dd88504a27b14bf6a5d46ce4d0

你懒,我也懒,前期迭代懒得优化,来一个需求,加一个if,久而久之,就串成了一座金字塔。

2fb9e596be6b4dfeab9bd0fb2769ef06

当代码已经复杂到难以维护的程度之后,只能狠下心重构优化。那,有什么方案可以优雅的优化掉这些多余的if/else?

\1. 提前return

这是判断条件取反的做法,代码在逻辑表达上会更清晰,看下面代码:

862cc54829bb4c7cb5554cdd61df0249

其实,每次看到上面这种代码,我都心里抓痒,完全可以先判断 !condition,干掉else。

18742bac0da146e4bf422cb49df84585

\2. 策略模式

有这么一种场景,根据不同的参数走不同的逻辑,其实这种场景很常见。

最一般的实现:

d38833d72dea4e48b28be4fb9b3eac4d

看上面代码,有4种策略,有两种优化方案。

2.1 多态

7ff854969741487cb7e94d549929203c

具体策略对象存放在一个Map中,优化后的实现

155979a9c134414cb0bf931e3abe4c5c

上面这种优化方案有一个弊端,为了能够快速拿到对应的策略实现,需要map对象来保存策略,当添加一个新策略的时候,还需要手动添加到map中,容易被忽略。

2.2 枚举

发现很多同学不知道在枚举中可以定义方法,这里定义一个表示状态的枚举,另外可以实现一个run方法。

f6d4a8257966429c8bb66732f5a8fe77

重新定义策略枚举

dfbbdcba9d29447f97f010e307f53248

通过枚举优化之后的代码如下

面试官:优化代码中大量的if/else,你有什么方案?

\3. 学会使用 Optional

Optional主要用于非空判断,由于是jdk8新特性,所以使用的不是特别多,但是用起来真的爽。

使用之前:

面试官:优化代码中大量的if/else,你有什么方案?

如果登录用户为空,执行action1,否则执行action 2,使用Optional优化之后,让非空校验更加优雅,间接的减少if操作

面试官:优化代码中大量的if/else,你有什么方案?

\4. 数组小技巧

来自google解释,这是一种编程模式,叫做表驱动法,本质是从表里查询信息来代替逻辑语句,比如有这么一个场景,通过月份来获取当月的天数,仅作为案例演示,数据并不严谨。

一般的实现:

面试官:优化代码中大量的if/else,你有什么方案?

优化后的代码

面试官:优化代码中大量的if/else,你有什么方案?

结束

if else作为每种编程语言都不可或缺的条件语句,在编程时会大量的用到。一般建议嵌套不要超过三层,如果一段代码存在过多的if else嵌套,代码的可读性就会急速下降,后期维护难度也大大提高。

原文地址:https://dwz.cn/J1JECdOr

博主关闭了所有页面的评论