写点什么

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

用户头像
朱季谦
关注
发布于: 2021 年 03 月 26 日
策略枚举:消除在项目里大批量使用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         此处省略10086行......15     }16 }
复制代码


这种代码,在业务逻辑里,少量还好,若是几百个判断呢,可能整块业务逻辑里都是满屏 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 话,着实是一件很影响性能的事情。


发布于: 2021 年 03 月 26 日阅读数: 9
用户头像

朱季谦

关注

一个以编程为生的荒诞小说家 2018.06.29 加入

汤圆创作APP签约作者; 简书优秀认证作者; Java后端程序员; PMP认证人员; 学生时代著有《黑色玫瑰》一书已上架微信读书APP;

评论

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