专栏首页网络小说作家的编程技术沉思录策略枚举:消除在项目里大批量使用if-else的正确姿势

策略枚举:消除在项目里大批量使用if-else的正确姿势

想起刚开始接触JAVA编程的时候,若遇到大量流程判断语句,几乎满屏都是if-else语句,多得让自己都忘了哪里是头,哪里是尾,但是,纵然满屏是if-else,但彼时也没有觉得多别扭。等到编程能力渐渐提升之后,再回过头去看曾经写过的满屏if-else时,脑海里只有一个画面,全都是翔.....

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

那么,如何消除在项目里大量使用if-else呢?

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

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

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

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

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

 1 //if-else形式判断
 2 public String getToDo(String day){
 3     if("Monday".equals(day)){
 4         return "今天上英语课";
 5     }else if("Tuesday".equals(day)){
 6         return "今天上语文课";
 7     }else if("Wednesday".equals(day)){
 8         return "今天上数学课";
 9     }else if("Thursday".equals(day)){
10         return "今天上音乐课";
11     }else if{
12         return "今天上编程课";
13     }else{
14         ......
15     }
16 }

这种代码,在业务逻辑里,少量还好,若是几百个判断呢,可能整块业务逻辑里都是满屏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()即可。

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

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

由此可知,若项目里有大量的if-else话,着实是一件很影响性能的事情。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • Java编程技巧:if-else优化实践总结归纳

    说实话,其实我很讨厌在代码里大量使用if-else,一是因为该类代码执行方式属于面向过程的,二嘛,则是会显得代码过于冗余。这篇笔记,主要记录一些自己在工作实践当...

    朱季谦
  • 一个技术总监的忠告:精通那么多技术为何还是做不好一个项目?

    编写高质量可维护的代码既是程序员的基本修养,也是能决定项目成败的关键因素,本文试图总结出问题项目普遍存在的共性问题并给出相应的解决方案。

    JAVA葵花宝典
  • Java中的大量if else语句的替代方案

    之前写过转载过一篇类似的不错的文章《除代码中的 if-else/switch-case的正确姿势》https://blog.csdn.net/w60528307...

    明明如月学长
  • SpringBoot 系列 JPA 错误姿势之 Entity 映射

    本篇为 JPA 错误使用姿势第二篇,java 的 POJO 类与数据库表结构的映射关系,除了驼峰命名映射为下划线之外,还会有什么别的坑么?

    一灰灰blog
  • 教你用策略模式解决多重if-else

    很多人可能在公司就是做普通的CRUD的业务,对于设计模式,即使学了好像也用处不大,顶多就在面试的时候能说上几种常见的单例模式,工厂模式。而在实际开发中,设计模式...

    java技术爱好者
  • if-else“烦不烦”,让代码简单、高效、优雅起来

    if else 是我们写代码时,使用频率最高的关键词之一,然而有时过多的 if else 会让我们感到想吃

    IT大咖说
  • 用好 Java 中的枚举,真的没有那么简单!

    在本文中,我们将看到什么是 Java 枚举,它们解决了哪些问题以及如何在实践中使用 Java 枚举实现一些设计模式。

    芋道源码
  • 【SpringBoot DB系列】Jooq批量写入采坑记录

    前面介绍了jooq的三种批量插入方式,结果最近发现这里面居然还有一个深坑,我以为的批量插入居然不是一次插入多条数据,而是一条一条的插入...,这就有点尬了

    一灰灰blog
  • (六)改掉这些坏习惯,还怕写不出精简的代码?

    上次讨论了一下如何借助注解来精简代码,代码修炼的系列分享,书接上篇,本次继续探讨一下:还有哪些奇淫技巧,能助力写出精简的代码?

    一猿小讲
  • 用好Java中的枚举,真的没有那么简单!

    在本文中,我们将看到什么是 Java 枚举,它们解决了哪些问题以及如何在实践中使用 Java 枚举实现一些设计模式。

    Guide哥
  • 用好 Java 中的枚举,让你的工作效率飞起来!

    在本文中,我们将看到什么是 Java 枚举,它们解决了哪些问题以及如何在实践中使用 Java 枚举实现一些设计模式。

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

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

    乔戈里
  • HandlerMethodArgumentResolver(四):自定参数解析器处理特定应用场景,介绍PropertyNamingStrategy的使用【享学Spring MVC】

    前面通过三篇文章介绍了HandlerMethodArgumentResolver这个参数解析器以及它的所有内置实现,相信看过的小伙伴对它的加载、初始化、处理原理...

    YourBatman
  • Java自定义注解开发

      最近在自己搞一个项目时,遇到可需要开发自定义注解的需求,对于没有怎么关注这些java新特性的来说,比较尴尬,索性就拿出一些时间,来进行研究下自定义注解开发的...

    阿豪聊干货
  • 【SpringBoot DB系列】Jooq批量写入采坑记录

    前面介绍了jooq的三种批量插入方式,结果最近发现这里面居然还有一个深坑,我以为的批量插入居然不是一次插入多条数据,而是一条一条的插入...,这就有点尬了

    一灰灰blog
  • SpringBoot下的策略模式,消灭了大量的ifelse,真香!

    项目中有这样一个场景,在公园放置了用来拍摄人像的识别杆,根据用户在不同识别杆之间采集的图象来计算用户的运动距离。由于涉及到许多公园,每个公园的布局不同,识别杆之...

    程序新视界
  • 改进异常处理的 6 条建议

    来源:ImportNew - 唐尤华 , 合理地使用异常处理可以帮你节省数小时(甚至数天)调试时间。一个乘法异常会毁掉你的晚餐乃至周末计划。如果处置不及时,甚至...

    企鹅号小编
  • 工作中常见的设计模式-策略模式

    最近准备学习下之前项目中用到的设计模式,这里代码都只展示核心业务代码,省略去大多不重要的代码。

    一枝花算不算浪漫
  • npoi批量导入实现及相关技巧

      批量导入功能对于大部分后台系统来说都是不可或缺的一部分,常见的场景-基础数据的录入(部门,用户),用批量导入方便快捷。最近项目需要用到批量导入,决定花点时间...

    用户1168362

扫码关注云+社区

领取腾讯云代金券