如何优化代码中大量的if/else,switch/case?

前言

随着项目的迭代,代码中存在的分支判断可能会愈来愈多,当里面涉及到的逻辑比较复杂或者分支数量实在是多的难以维护的时候,咱们就要考虑下,有办法能让这些代码变得更优雅吗?java

正文

使用枚举

这里咱们简单的定义一个表示状态的枚举。git

public enum Status {
    NEW(0),RUNNABLE(1),RUNNING(2),BLOCKED(3),DEAD(4);

    public int statusCode;

    Status(int statusCode){
        this.statusCode = statusCode;
    }
}

那么咱们在使用的时候就能够直接经过枚举调用了。github

int statusCode = Status.valueOf("NEW").statusCode;

优雅的解决了下面代码赋值的方式web

if(param.equals("NEW")){
    statusCode = 0;
}else if(param.equals("RUNNABLE")){
    statusCode = 1;
}
...

善用 Optional

在项目中,总少不了一些非空的判断,可能大部分人仍是以下的用法编程

if(null == user){
    //action1
}else{
    //action2
}

这时候该掏出Optional这个秘密武器了,它可让非空校验更加优雅,间接的减小if操做。没了解过Optional的同窗可自行Google,这里就再也不赘述。设计模式

Optional<User> userOptional = Optional.ofNullable(user);
userOptional.map(action1).orElse(action2);

上面的代码跟第一段是等效的,经过一些新特性让代码更加紧凑。数组

表驱动法

来自Google的解释:表驱动法是一种编程模式,它的本质是,从表里查询信息来代替逻辑语句(if,case)。下面看一个案例,经过月份来获取当月的天数(仅做为案例演示,获取2月份的数据不严谨),普通作法:app

int getMonthDays(int month){
	switch(month){
		case 1:return 31;break;
		case 2:return 29;break;
		case 3:return 31;break;
		case 4:return 30;break;
		case 5:return 31;break;
		case 6:return 30;break;
		case 7:return 31;break;
		case 8:return 31;break;
		case 9:return 30;break;
		case 10:return 31;break;
		case 11:return 30;break;
		case 12:return 31;break;
		defaultreturn 0;
	}
}

表驱动法实现方式svg

int monthDays[12] = {31, 29, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31};
int getMonthDays(int month){
	return monthDays[--month];
}

其实这里的表就是数组而已,经过直接查询数组来得到须要的数据,那么同理,Map之类的容器也能够成为咱们编程概念中的表。优化

Map<?, Function<?> action> actionsMap = new HashMap<>();

// 初试配置对应动做
actionsMap.put(value1, (someParams) -> { doAction1(someParams)});
actionsMap.put(value2, (someParams) -> { doAction2(someParams)});
actionsMap.put(value3, (someParams) -> { doAction3(someParams)});
 
// 省略 null 判断
actionsMap.get(param).apply(someParams);

经过Java8的lambda表达式,咱们把须要执行东西存进value中,调用的时候经过匹配key的方式进行。

提早判断返回

在以前的文章《优化代码中的“坏味道”》里也有提过,以下语句

if(condition){
   //dost
}else{
   return ;
}

改成

if(!condition){
   return ;
}
//dost

避免一些没必要要的分支,让代码更精炼。

其余方法

除了上面提到的方法,咱们还能够经过一些设计模式,例如策略模式,责任链模式等来优化存在大量if,case的状况,其原理会和表驱动的模式比较类似,你们能够本身动手实现一下,例如咱们在Netty的使用过程当中,可能会出现须要大量判断不一样的命令去执行对应动做的场景。

ServerHandler.java

if(command.equals("login")){
    //执行登陆
}else if(command.equals("chat")){
    //聊天
}else if(command.equals("broadcast")){
    //广播信息
}
....

该如何处理呢?这里先卖个关子,你们能够先思考一下,笔记后续会写一些关于Netty实现IM的文章,到时候会详细介绍。

结语

最后要明确一点,不是全部的if/else,switch/case都须要优化,当咱们发现有“痛点”或者“闻到代码有坏味道”再来优化才是最好的,否则你可能会写了一个从不扩展的可扩展代码,全部的优化都是为了更好的迭代项目,更好的服务于业务,而不是为了优化而优化。


公众号博文同步Github仓库,有兴趣的朋友能够帮忙给个Star哦,码字不易,感谢支持。

https://github.com/PeppaLittlePig/blog-wechat

推荐阅读

如何提升使用Java反射的效率?
Java日志正确使用姿式
论JVM爆炸的几种姿式及自救方法

有收获的话,就点个赞吧

关注「深夜里的程序猿」,分享最干的干货