答应我,别再if/else走天下了可以吗

 哎,曾几何时  

想当年,其实我也特别钟情于 if/else 连环写法,上来就是一顿 SAO操作 ,比如 举个好理解的简单栗子

一般来说我们正常的后台管理系统都有所谓的角色的概念,不同管理员权限不一样,能够行使的操作也不一样,比如:

  • 系统管理员(   ROLE_ROOT_ADMIN ):有   A 操作权限

  • 订单管理员(   ROLE_ORDER_ADMIN ):有   B 操作权限

  • 普通用户( ROLE_NORMAL ):有   C 操作权限

比如一个用户进来,我们需要根据不同用户的角色来判断其有哪些行为,这时候 SAO代码 出现了:

这样当系统里有 几十个角色 时,那几十个 if/else 嵌套可以说是非常酸爽了…… 这样 一来 非常不优雅,别人阅读起来很费劲; 二来 则是以后如果再复杂一点,或者想要再加条件的话 不好扩展 ;而且代码一改,以前的老功能肯定还得重测,岂不疯了……

所以,如果在不看下文的情况下,你一般会如何去对付这些令人头痛的if/else语句呢?

当然有人会说用 switch/case 来写是否会优雅一些呢?答案是: 毛区别都没有

接下来简单讲几种改进方式,别再 if/else 走天下了

 有枚举为啥不用  

什么角色能干什么事,这很明显有一个对应关系,所以学过的枚举为啥不用呢?

首先定义一个公用接口 RoleOperation ,表示不同角色所能做的操作:

接下来我们将不同角色的情况全部交由枚举类来做,定义一个不同角色有不同权限的枚举类 RoleEnum

接下来调用就变得异常简单了,一行代码就行了, if/else 也灰飞烟灭了:

而且这样一来,以后假如我想扩充条件,只需要去枚举类中加代码即可,而不是去改以前的代码,这岂不很稳!

除了用枚举来消除 if/else ,工厂模式也可以实现

 有工厂模式为啥不用  

不同分支做不同的事情,很明显就提供了使用工厂模式的契机,我们只需要将不同情况单独定义好,然后去工厂类里面 聚合 即可。

首先,针对不同的角色,单独定义其业务类:

接下来再写一个 工厂类 RoleFactory 对上面不同角色进行聚合:

接下来借助上面这个工厂,业务代码调用也只需一行代码, if/else 同样被消除了:

这样的话以后想扩展条件也很容易,只需要增加新代码,而不需要动以前的业务代码,非常符合 “开闭原则”

来,我们接着来,除了工厂模式,策略模式也不妨试一试

 有策略模式为啥不用  

策略模式和工厂模式写起来其实区别也不大!

在上面工厂模式代码的基础上,按照策略模式的指导思想,我们也来创建一个所谓的 策略上下文类 ,这里命名为 RoleContext

很明显上面传入的参数 operation 就是表示不同的 “策略” 。我们在业务代码里传入不同的角色,即可得到不同的操作结果:

 共   勉  

好了,先讲到这里吧,本文仅仅是抛砖引玉,使用了一个极其简单的示例来打了个样,然而其思想可以广泛地应用于实际复杂的业务和场景,思想真的很重要!写代码前还是得多思考一番,考虑是否有更具可扩展性的写法!

后   记

若有错误或者不当之处,可在本公众号内反馈,一起学习交流!

更多热文在此:

   ●   Spring Boot 系列实战文章合集(源码已开源)

●   程序员写简历时必须注意的技术词汇拼写

●   前后端都分离了,该搞个好用的API管理系统了!

●   从一份配置清单详解Nginx服务器配置

●   如何在Windows下像Mac一样优雅的开发

●   Docker容器可视化监控中心搭建

●   利用ELK搭建Docker容器化应用日志中心

●   真实IT领域2/8法则,扎心了!

●   一文详解 Linux系统常用监控工具

更多 务实、能看懂、可复现的 技术文章、资源尽在公众号 CodeSheep ,欢迎扫码订阅,第一时间获取更新 :arrow_down::arrow_down::arrow_down:

我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章