答应我,别再if/else走天下了可以吗
哎,曾几何时
想当年,其实我也特别钟情于 if/else连环写法,上来就是一顿SAO操作,比如举个好理解的简单栗子:
一般来说我们正常的后台管理系统都有所谓的角色的概念,不同管理员权限不一样,能够行使的操作也不一样,比如:
- 系统管理员( ROLE_ROOT_ADMIN):有 A操作权限
订单管理员( ROLE_ORDER_ADMIN):有 B操作权限
- 普通用户( ROLE_NORMAL):有 C操作权限
比如一个用户进来,我们需要根据不同用户的角色来判断其有哪些行为,这时候SAO代码出现了:
public class JudgeRole { public String judge( String roleName ) { String result = ""; if (roleName.equals("ROLE_ROOT_ADMIN")) { // 系统管理员有A权限 result = "ROLE_ROOT_ADMIN: " + "has AAA permission"; } else if ( roleName.equals("ROLE_ORDER_ADMIN") ) { // 订单管理员有B权限 result = "ROLE_ORDER_ADMIN: " + "has BBB permission"; } else if ( roleName.equals("ROLE_NORMAL") ) { // 普通用户有C权限 result = "ROLE_NORMAL: " + "has CCC permission"; } else { result = "XXX"; } return result; }}
这样当系统里有几十个角色时,那几十个 if/else嵌套可以说是非常酸爽了…… 这样一来非常不优雅,别人阅读起来很费劲;二来则是以后如果再复杂一点,或者想要再加条件的话不好扩展;而且代码一改,以前的老功能肯定还得重测,岂不疯了……
所以,如果在不看下文的情况下,你一般会如何去对付这些令人头痛的if/else语句呢?
当然有人会说用 switch/case来写是否会优雅一些呢?答案是:毛区别都没有!
接下来简单讲几种改进方式,别再 if/else走天下了
有枚举为啥不用
什么角色能干什么事,这很明显有一个对应关系,所以学过的枚举为啥不用呢?
首先定义一个公用接口 RoleOperation,表示不同角色所能做的操作:
public interface RoleOperation { String op(); // 表示某个角色可以做哪些op操作}
接下来我们将不同角色的情况全部交由枚举类来做,定义一个不同角色有不同权限的枚举类 RoleEnum:
public enum RoleEnum implements RoleOperation { // 系统管理员(有A操作权限) ROLE_ROOT_ADMIN { @Override public String op() { return "ROLE_ROOT_ADMIN:" + " has AAA permission"; } }, // 订单管理员(有B操作权限) ROLE_ORDER_ADMIN { @Override public String op() { return "ROLE_ORDER_ADMIN:" + " has BBB permission"; } }, // 普通用户(有C操作权限) ROLE_NORMAL { @Override public String op() { return "ROLE_NORMAL:" + " has CCC permission"; } };}
接下来调用就变得异常简单了,一行代码就行了, if/else也灰飞烟灭了:
public class JudgeRole { public String judge( String roleName ) { // 一行代码搞定!之前的if/else没了! return RoleEnum.valueOf(roleName).op(); }}
而且这样一来,以后假如我想扩充条件,只需要去枚举类中加代码即可,而不是去改以前的代码,这岂不很稳!
除了用枚举来消除 if/else,工厂模式也可以实现
有工厂模式为啥不用
不同分支做不同的事情,很明显就提供了使用工厂模式的契机,我们只需要将不同情况单独定义好,然后去工厂类里面聚合即可。
首先,针对不同的角色,单独定义其业务类:
// 系统管理员(有A操作权限)public class RootAdminRole implements RoleOperation { private String roleName; public RootAdminRole( String roleName ) { this.roleName = roleName; } @Override public String op() { return roleName + " has AAA permission"; }}// 订单管理员(有B操作权限)public class OrderAdminRole implements RoleOperation { private String roleName; public OrderAdminRole( String roleName ) { this.roleName = roleName; } @Override public String op() { return roleName + " has BBB permission"; }}// 普通用户(有C操作权限)public class NormalRole implements RoleOperation { private String roleName; public NormalRole( String roleName ) { this.roleName = roleName; } @Override public String op() { return roleName + " has CCC permission"; }}
接下来再写一个工厂类 RoleFactory对上面不同角色进行聚合:
public class RoleFactory { static Map<String, RoleOperation> roleOperationMap = new HashMap<>(); // 在静态块中先把初始化工作全部做完 static { roleOperationMap.put( "ROLE_ROOT_ADMIN", new RootAdminRole("ROLE_ROOT_ADMIN") ); roleOperationMap.put( "ROLE_ORDER_ADMIN", new OrderAdminRole("ROLE_ORDER_ADMIN") ); roleOperationMap.put( "ROLE_NORMAL", new NormalRole("ROLE_NORMAL") ); } public static RoleOperation getOp( String roleName ) { return roleOperationMap.get( roleName ); }}
接下来借助上面这个工厂,业务代码调用也只需一行代码, if/else同样被消除了:
public class JudgeRole { public String judge( String roleName ) { // 一行代码搞定!之前的 if/else也没了! return RoleFactory.getOp(roleName).op(); }}
这样的话以后想扩展条件也很容易,只需要增加新代码,而不需要动以前的业务代码,非常符合“开闭原则”。
来,我们接着来,除了工厂模式,策略模式也不妨试一试
有策略模式为啥不用
策略模式和工厂模式写起来其实区别也不大!
在上面工厂模式代码的基础上,按照策略模式的指导思想,我们也来创建一个所谓的策略上下文类,这里命名为 RoleContext:
public class RoleContext { // 可更换的策略,传入不同的策略对象,业务即相应变化 private RoleOperation operation; public RoleContext( RoleOperation operation ) { this.operation = operation; } public String execute() { return operation.op(); }}
很明显上面传入的参数 operation就是表示不同的“策略”。我们在业务代码里传入不同的角色,即可得到不同的操作结果:
public class JudgeRole { public String judge( RoleOperation roleOperation ) { RoleContext roleContext = new RoleContext( roleOperation ); return roleContext.execute(); }}public static void main( String[] args ) { JudgeRole judgeRole = new JudgeRole(); String result1 = judgeRole.judge(new RootAdminRole("ROLE_ROOT_ADMIN")); System.out.println( result1 ); String result2 = judgeRole.judge(new OrderAdminRole("ROLE_ORDER_ADMIN")); System.out.println( result2 ); String result3 = judgeRole.judge(new NormalRole("ROLE_NORMAL")); System.out.println( result3 );}
共 勉
好了,先讲到这里吧,本文仅仅是抛砖引玉,使用了一个极其简单的示例来打了个样,然而其思想可以广泛地应用于实际复杂的业务和场景,思想真的很重要!写代码前还是得多思考一番,考虑是否有更具可扩展性的写法!
后 记
若有错误或者不当之处,可在本公众号内反馈,一起学习交流!
更多热文在此:
● Spring Boot 系列实战文章合集(源码已开源)
● 程序员写简历时必须注意的技术词汇拼写
● 前后端都分离了,该搞个好用的API管理系统了!
● 从一份配置清单详解Nginx服务器配置
● 如何在Windows下像Mac一样优雅的开发
● Docker容器可视化监控中心搭建
● 利用ELK搭建Docker容器化应用日志中心
● 真实IT领域2/8法则,扎心了!
● 一文详解 Linux系统常用监控工具
更多 务实、能看懂、可复现的 技术文章、资源尽在公众号 CodeSheep,欢迎扫码订阅,第一时间获取更新 ⬇️⬇️⬇️
©著作权归作者所有:来自51CTO博客作者mb5fdcae83766b7的原创作品,如需转载,请注明出处,否则将追究法律责任更多相关文章
- 37000 字 + 代码,艿艿肝的 Shiro 从入门到实战,直接收藏吃灰!
- 44000 字 + 代码,艿艿肝的 Spring Security 从入门到实战,直接收藏
- Linux学习:文件IO(不带缓冲区),原子操作概念
- Apollo 源码解析 —— Config Service 操作审计日志 Audit
- Spring 异步调用,一行代码实现!舒服,不接受任何反驳~
- Spring Boot项目利用MyBatis Generator进行数据层代码自动生成
- 【第562期】用 webpack 构建 node 后端代码,使其支持 js 新特性并
- 怎样编写更好的 JavaScript 代码[每日前端夜话0xA4]
- 芋道 Spring Boot 消除冗余代码 Lombok 入门