你还想if/else用多久?来学学这几种改进方式吧

发表于:2019-12-18 13:13

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:佚名    来源:Java之高级架构

#
java
#
Java
分享:
  哎,曾几何时
  想当年,其实我也特别钟情于 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:
  接下来调用就变得异常简单了,一行代码就行了, if/else也灰飞烟灭了:
   public class JudgeRole {
  public String judge( String roleName ) {
  // 一行代码搞定!之前的if/else没了!
  return RoleEnum.valueOf(roleName).op();
  }
  }
  而且这样一来,以后假如我想扩充条件,只需要去枚举类中加代码即可,而不是去改以前的代码,这岂不很稳!
  除了用枚举来消除 if/else,工厂模式也可以实现
  有工厂模式为啥不用
  不同分支做不同的事情,很明显就提供了使用工厂模式的契机,我们只需要将不同情况单独定义好,然后去工厂类里面聚合即可。
  首先,针对不同的角色,单独定义其业务类:
  
  接下来再写一个工厂类 RoleFactory对上面不同角色进行聚合:
  接下来借助上面这个工厂,业务代码调用也只需一行代码, if/else同样被消除了:
   public class JudgeRole {
  public String judge( String roleName ) {
  // 一行代码搞定!之前的 if/else也没了!
  return RoleFactory.getOp(roleName).op();
  }
  }
  这样的话以后想扩展条件也很容易,只需要增加新代码,而不需要动以前的业务代码,非常符合“开闭原则”。
  来,我们接着来,除了工厂模式,策略模式也不妨试一试
  有策略模式为啥不用
  策略模式和工厂模式写起来其实区别也不大!
  在上面工厂模式代码的基础上,按照策略模式的指导思想,我们也来创建一个所谓的策略上下文类,这里命名为 RoleContext:
  
  很明显上面传入的参数 operation就是表示不同的“策略”。我们在业务代码里传入不同的角色,即可得到不同的操作结果:
  

      本文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号