代码优雅之道! 如何干掉过多的 if else

本文讨论了在实际开发中如何优化判断条件众多的代码,对比了ifelse和switch的适用场景,提出在业务逻辑复杂时使用策略模式和Map结合函数式接口的方法,以及其优缺点和适用范围。
摘要由CSDN通过智能技术生成

实际开发中我们经常遇到判断条件很多的情况,比如下图有20多种情况,不用想肯定是要优化代码的,需要思考的是如何去优化?

图片

if else能够把复杂的逻辑关系表达得清晰、易懂,包容了程序执行的各种情况。

switch不适合业务系统的实际复杂需求,业务不断的变更迭代,一更改需求,条件的复杂度高了,switch无力处理。

switch经常忘记写break,估计很多人一不小心就忘记写了。

switch…case只能处理case为常量的情况。

当情况不大于5种并且单一变量的值(如枚举),此时我们就可以使用switch,它的可读性比if条件更清晰。

除了上述说到枚举的这种场景,建议使用switch,其他个人愚见:只要情况不大于5种就直接使用if else

3策略+工厂模式

上述说到情况较少时并且业务逻辑不复杂的使用if else可以让代码清晰明了。当每种情况对应的业务逻辑复杂时,建议使用策略+工厂模式。这里我们举个栗子:厂家每个季度要举行不同的活动,我们使用策略工厂模式来实现

策略接口

public interface Strategy {

    /**
     * 处理各种活动
     * @return
     */
    String dealActivity();
}

然后春夏秋冬四季活动类实现该接口

图片

@Service
public class SpringActivity implements Strategy{
    @Override
    public String dealActivity() {
        return "春季活动逻辑";
    }
}

策略类工厂

图片

然后在service层中传入对应的编码即可 ,我这里省略了service

图片

图片

上述已经干掉了if else ,后续季度活动调整去修改对应活动策略类中逻辑即可。

缺点:如果情况比这多,那么策略类会越来越多,也就是所谓的策略类膨胀,并且没有一个地方可以俯视整个业务逻辑。

4Map+函数式接口

将上述策略类全部作为方法。Map+函数式接口优化的方法,可以参考这里,讲解的比较细致:Map+函数式接口,“更完美” 的解决 if-else的问题

图片

再写个活动Service

图片

改变Controller

图片

最后说一句(求关注!别白嫖!)

如果这篇文章对您有所帮助,或者有所启发的话,求一键三连:点赞、转发、在看。

关注公众号:woniuxgg,在公众号中回复:笔记  就可以获得蜗牛为你精心准备的java实战语雀笔记,回复面试、开发手册、有超赞的粉丝福利!

  • 33
    点赞
  • 10
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值