如何避免在Java项目里大批量使用if-else?

避免大批量使用if-else

可能初学者都会忽略掉一点,其实if-else是一种面向过程的实现。

那么,如何避免在面向对象编程里大量使用if-else呢?

网络上有很多解决思路,有工厂模式、策略模式、甚至是规则引擎(这个太重了吧)......

这些,都有一个共同的缺点,使用起来还是过于繁重了。虽说避免出现过多的if-else,但是,却会增加很多额外的类,我总觉得,很不实用,只能当做某种模式的学习即可。

可以替换大量的if-else语句,且具备较好的可读性与扩展性,同时能显得轻量化,我比较推荐使用策略枚举来消除if-else。

如何使用呢,下面先从一个业务案例开始说起下——

假如有这样一个需求,需实现一周七天内分别知道要做事情的备忘功能,这里面就会涉及到一个流程判断,你可能会立马想到用if-else,那么,可能是会这样实现——

//if-else形式判断
  public String getToDo(String day){
      if("Monday".equals(day)){
          ......省略复杂语句
         return "今天上英语课";
     }else if("Tuesday".equals(day)){
          .....省略复杂语句
          return "今天上语文课";
     }else if("Wednesday".equals(day)){
         ......省略复杂语句
         return "今天上数学课";
      }else if("Thursday".equals(day)){
         ......省略复杂语句
        return "今天上音乐课";
    }else if("sunday".equals(day)){
         ......省略复杂语句
        return "今天上编程课";
     }else{
         此处省略10086行......
     }
 }

这种代码,在业务逻辑里,少量还好,若是几百个判断呢,可能整块业务逻辑里都是满屏if-else,既不优雅也显得很少冗余。

这时,就可以考虑使用策略枚举形式来替换这堆面向过程的if-else实现了。

首先,先定义一个getToDo()调用方法,假如传进的是“星期一”,即参数"Monday"。

//策略枚举判断
public String getToDo(String day){
    CheckDay checkDay=new CheckDay();
    return checkDay.day(DayEnum.valueOf(day));
}

在getToDo()方法里,通过DayEnum.valueOf("Monday")可获取到一个DayEnum枚举元素,这里得到的是Monday。

接下来,执行checkDay.day(DayEnum.valueOf("Monday")),会进入到day()方法中,这里,通过dayEnum.toDo()做了一个策略匹配时。注意一点,DayEnum.valueOf("Monday")得到的是枚举中的Monday,这样,实质上就是执行了Monday.toDo(),也就是说,会执行Monday里的toDo()——

public class CheckDay {
    public String day( DayEnum dayEnum) {
        return dayEnum.toDo();
    }
}

上面的执行过程为什么会是这样子呢?只有进入到DayEnum枚举当中,才知道是怎么回事了——(话外音:我第一次接触策略模式时,猛地一惊,原来枚举还可以这样玩)

public enum DayEnum {
    Monday {
        @Override
        public String toDo() {
            ......省略复杂语句
            return "今天上英语课";
        }
    },
    Tuesday {
        @Override
        public String toDo() {
            ......省略复杂语句
            return "今天上语文课";
        }
    },
    Wednesday {
        @Override
        public String toDo() {
            ......省略复杂语句
            return "今天上数学课";
        }
    },
    Thursday {
        @Override
        public String toDo() {
            ......省略复杂语句
            return "今天上音乐课";
        }
    };
    public abstract String toDo();
}

在DayEnum枚举属性当中,定义了一个实现了toDo()抽象方法——

public abstract String toDo();

在每个枚举元素当中,都重写了该toDo()抽象方法。这样,当传参DayEnum.valueOf("Monday")流转到dayEnum.toDo()时,实质上是去DayEnum枚举里找到对应Monday定义的枚举元素,然后执行其内部重写的toDo()方法。用if-esle形式表示,就类似"Monday".equals(day)匹配为true时,可得到其内部东西。

总结一下,策略枚举就是枚举当中使用了策略模式,所谓的策略模式,即给你一把钥匙,按照某种约定的方式,可以立马被指引找到可以打开的门。例如,我给你的钥匙叫“Monday”,那么,就可以通过约定方式dayEnum.toDo(),立马找到枚举里的Monday大门,然后进到门里,去做想做的事toDo(),其中,每扇门后的房间都有不同的功能,但它们都有一个相同抽象功能——toDo(),即各房间共同地方都是可以用来做一些事情的功能,但具体可以什么事情,就各有不同了。在本文的案例里,每扇大门里的toDo(),根据不同策略模式可得到不同字符串返回,例如,"今天上英语课"、"今天上语文课",等等。

可见,把流程判断抽取到策略枚举当中,还可以把一堆判断解耦出来,避免在业务代码逻辑里呈现一大片密密麻麻冗余的if-else。

这里,会出现一种情况,即,假如有多个重复共同样功能的判断话,例如,在if-else里,是这样——

public String getToDoByIfElse(String day){
    if("Monday".equals(day)||"Tuesday".equals(day)||"Wednesday".equals(day)){
        ......省略复杂语句
        return "今天上英语课";
    }else if("Thursday".equals(day)){
        ......
    }
}

那么,在策略枚举下应该如何使用从而避免代码冗余呢?

可以参考一下以下思路,设置一个内部策略枚举,将有相同功能的外部引用指向同一个内部枚举元素,这样即可实现调用重复功能了——

public enum DayEnum {
    //指向内部枚举的同一个属性即可执行相同重复功能
    Monday("星期一", Type.ENGLISH),
    Tuesday("星期二", Type.ENGLISH),
    Wednesday("星期三", Type.ENGLISH),
    
    Thursday("星期四", Type.CHINESE);
    private final Type type;
    private final String day;
    DayEnum(String day, Type type) {
        this.day = day;
        this.type = type;
    }
    String toDo() {
        return type.toDo();
    }
    /**
     * 内部策略枚举
     */
    private enum Type {
        ENGLISH {
            @Override
            public String toDo() {
                ......省略复杂语句
                return "今天上英语课";
            }
        },
        CHINESE {
            @Override
            public String toDo() {
                ......省略复杂语句
                return "今天上语文课";
            }
        };
        public abstract String toDo();
    }
}

若要扩展其判断流程,只需要直接在枚举增加一个属性和内部toDo(实现),就可以增加新的判断流程了,而外部,仍旧用同一个入口dayEnum.toDo()即可。

可能,会有这样一个疑问:为什么在枚举里定义一个抽象方法,会在各个枚举元素里实现呢?

这功能就类似子类继承父类的做法了。DayEnum类似一个父类,DayEnum枚举里的元素就相当是其子类。当父类里定义了抽象方法toDo(),其继承的子类就会默认实现toDo()方法,这样,就会出现枚举里可以这样的写法:

private enum Type {
        ENGLISH {
            @Override
            public String toDo() {
                return "今天上英语课";
            }
        };
        public abstract String toDo();
    }

我很喜欢在大批量if-else里使用策略枚举来消除替换,总而言之,使用策略枚举可以很灵活处理各种复杂判断,且可读性与扩展性都比较好,它更像是函数式编程,即传进一个参数,就可以得到对应模式下返回的数值。

若Java里业务逻辑中大批量使用if-else,则是面向过程了,因为业务逻辑里的if-else是从上往下一个if接一个if判断下去的,在各个if上打个断点,debug下去,就明白它其实是面向过程的。

由此可知,若项目里有大量的if-else话,着实是一件很影响性能的事情,虽然这点性能可忽略不计,但有更好的取代方案,不是更好吗?

到此这篇关于如何避免在Java项目里大批量使用if-else?的文章就介绍到这了,更多相关避免大批量使用if-else内容请搜索179885.Com以前的文章或继续浏览下面的相关文章希望大家以后多多支持179885.Com!

猜你在找的如何避免在Java项目里大批量使用if-else?相关文章

本文将结合实例代码,介绍SpringBoot+Redis实现后端接口防重复提交校验的示例,具有一定的参考价值,感兴趣的小伙伴们可以参考一下
CompletableFuture是java8提供的基于异步操作的封装,日常开发中经常会用到,接下来通过本文给大家介绍Java8 CompletableFuture 异步执行操作,感兴趣的朋友一起看看吧
今天带大家学习的是关于Java进阶的相关知识,文章围绕着Java泛型机制与反射原理展开,文中有非常详细的介绍及代码示例,需求的大佬可以参考下
了解决eclipse启动tomcat时不能加载web项目的问题,具有很好的参考价值,希望对大家有所帮助。如有错误或未考虑完全的地方,望不吝赐教
Spring是于2003 年兴起的一个轻量级的Java 开发框架,由Rod Johnson创建。简单来说,Spring是一个分层的JavaSE/EE full-stack(一站式) 轻量级开源框架
了Spring Security之默认的过滤器链及自定义Filter操作,具有很好的参考价值,希望对大家有所帮助。如有错误或未考虑完全的地方,望不吝赐教
JNI是Java Native Interface的缩写,通过使用 Java本地接口书写程序,可以确保代码在不同的平台上方便移植。从Java1.1开始,JNI标准成为java平台的一部分,它允许Java代
今天给大家带来的是关于Java虚拟机的相关知识,文章围绕着JVM堆区展开,文中有非常详细的介绍及代码示例,需求的大佬可以参考下
本篇总结的是Java多线程相关的面试题,后续会持续更新,希望我的分享可以帮助到正在备战面试的实习生或者已经工作的同行,如果发现错误还望大家多多包涵,不吝赐教,谢谢
Spring为大家内置了不少开箱即用的转换类,如字符串转数字、字符串转时间等,但有时候需要使用自定义的属性,则需要自定义转换类了
今天给大家带来的是关于Java的相关知识,文章围绕着在没有编辑器的环境下如何创建Servlet(Tomcat+Java)项目展开,文中有非常详细的介绍及代码示例,需求的大佬可以
文详细讲述了线程、进程的关系及在操作系统中的表现,这是多线程学习必须了解的基础。本文将接着讲一下Java线程同步中的一个重要的概念synchronized,希望能够给你有