干掉过多的 if else,让你的代码更优雅

干掉过多的 if else,让你的代码更优雅

学习改变命运,技术铸就辉煌。

大家好,我是銘,全栈开发程序员。

写代码时候,有时候条件过多,会有很多 if else ,代码看起来很乱,不够优雅,那如何让代码更优雅呢,如何让代码可读性更强呢,那銘哥就来教你怎么做。

注意啊,是过的 if-else ,如果只是三四个,那就没必要优化了。

image-20240114225917651

写这篇文章之前,我看网上很多说用 switch case 啊,首先不比较 if else 与 switch case 效率问题的,只从代码整洁度来看二者没啥区别啊!我们这里更重要的是代码整洁度问题,为什么呢?来看下文的比较。

If else与switch case效率真的差距很大么?

网上有两种见解:

第一种是说switch…case会生成一个跳转表来指示实际的case分支的地址,而这个跳转表的索引号与switch变量的值是相等的。从而,switch…case不用像if…else那样遍历条件分支直到命中条件,而只需访问对应索引号的表项从而到达定位分支的目的。简单来说就是以空间换时间

第二种是说二者效率上差距并不大

image-20240114230033405

于是銘哥自己去体验一下,不存在复杂业务逻辑,仅仅比较两种方式的效率:

void contextLoads() {
    testIf(100000);
    System.gc();
    testSwitch(100000);
}

private void testIf(Integer param) {
    long start = System.currentTimeMillis();
    for (int i = 0; i < param; i++) {
        if (i == param-1){
            System.out.println("if判断100000次");
        }
    }
    long end = System.currentTimeMillis();
    long total = end - start;
    System.out.println("Test消耗时间:" + total);
}

private void testSwitch(Integer param){
    long start = System.currentTimeMillis();
    for (int i = 0; i < param; i++) {
        switch (i){
            case 99999:
                System.out.println("switch判断100000次");
                break;
        }
    }
    long end = System.currentTimeMillis();
    long total = end - start;
    System.out.println("Test消耗时间:" + total);
}

图片

可见差距并不大。而情况太多的时候谁还会去用 if else 和 switch case 呢?下面还是对两种方式的使用场景做简单的分析:

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

switch 不适合业务系统的实际复杂需求,业务不断的变更迭代,一更改需求,条件的复杂度高了,switch 无力处理。switch 经常忘记写 break,估计很多人一不小心就忘记写了。switch…case 只能处理case 为常量的情况。当情况不大于5种并且单一变量的值(如枚举),此时我们就可以使用 switch,它的可读性比 if 条件更清晰。

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

策略+工厂模式

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

策略接口

public interface Strategy {

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

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

图片

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

策略类工厂

public class StrategyFactory {
    public static Strategy execute(Integer levelCode){
        Strategy strategy = null;
        switch (levelCode){
            case 1:
                strategy = new SpringActivity();
                break;
            case 2:
                strategy = new SummerActivity();
                break;
            case 3:
                strategy = new AutumnActivity();
                break;
            case 4:
                strategy = new WinterActivity();
                break;
            default:
                throw new IllegalArgumentException("活动编号错误");
        }
        return strategy;
    }
}

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

@RestController
public class TestController {

    @PostMapping("/dealActivity")
    public String dealActivity(Integer code){
        Strategy strategy = StrategyFactory.execute(1);
        return strategy.dealActivity();
    }
}

图片

上述已经干掉了if else ,后续季度活动调整去修改对应活动策略类中逻辑即可。缺点:如果情况比这多,那么策略类会越来越多,也就是所谓的策略类膨胀,并且没有一个地方可以俯视整个业务逻辑

Map+函数式接口

@Service
public class ActivityStrategyService {

    public String dealSpringActivity(){
        return "春季活动逻辑";
    }
    
    public String dealSummerActivity() {
        return "夏季活动逻辑";
    }

    public String dealAutumnActivity() {
        return "秋季活动逻辑";
    }

    public String dealWinterActivity() {
        return "冬季活动逻辑";
    }
}

再写个活动Service

@Service
public class ActivityService {

    @Autowired
    private ActivityStrategyService activityStrategyService;

    @FunctionalInterface
    interface ActivityFunction<A>{
        //这里可以传参啊,我这里举例用不上参数
        //String dealActivity(A a);
     String dealActivity();
    }

    private final Map<Integer, ActivityFunction> strategyMap = new HashMap<>();

    /**
     * 初始化策略
     */
    @PostConstruct
    public void initDispatcher(){
        strategyMap.put(1,()->activityStrategyService.dealSpringActivity());
        strategyMap.put(2, ()-> activityStrategyService.dealSummerActivity());
        strategyMap.put(3, ()-> activityStrategyService.dealAutumnActivity());
        strategyMap.put(4, ()-> activityStrategyService.dealWinterActivity());
    }

    public String dealActivity(Integer code){
        ActivityFunction<Integer> function = strategyMap.get(code);
        //这里防止活动编号没匹配上,可以使用断言来判断从而抛出统一异常
        return function.dealActivity();
    }

}

改变Controller

@RestController
public class TestController {

    @Autowired
    private ActivityService activityService;

    @PostMapping("/dealActivity")
    public String dealActivity(Integer code){
//        Strategy strategy = StrategyFactory.execute(1);
//        return strategy.dealActivity();
        return activityService.dealActivity(code);
    }
}
posted @   銘聊技术  阅读(41)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· 【.NET】调用本地 Deepseek 模型
· CSnakes vs Python.NET:高效嵌入与灵活互通的跨语言方案对比
· DeepSeek “源神”启动!「GitHub 热点速览」
· 我与微信审核的“相爱相杀”看个人小程序副业
· Plotly.NET 一个为 .NET 打造的强大开源交互式图表库
点击右上角即可分享
微信分享提示