查看原文
其他

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

脚本之家 2021-06-30

The following article is from CodeSheep Author hansonwong99

  脚本之家

你与百万开发者在一起

来源微信公众号:CodeSheep

如若转载请联系原公众号


 哎,曾几何时 

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

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

  • 系统管理员( ROLE_ROOT_ADMIN):有 A操作权限
  • 订单管理员( ROLE_ORDER_ADMIN):有 B操作权限
  • 普通用户( ROLE_NORMAL):有 C操作权限

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

  1. public class JudgeRole {


  2. public String judge( String roleName ) {

  3. String result = "";

  4. if (roleName.equals("ROLE_ROOT_ADMIN")) { // 系统管理员有A权限

  5. result = "ROLE_ROOT_ADMIN: " + "has AAA permission";

  6. } else if ( roleName.equals("ROLE_ORDER_ADMIN") ) { // 订单管理员有B权限

  7. result = "ROLE_ORDER_ADMIN: " + "has BBB permission";

  8. } else if ( roleName.equals("ROLE_NORMAL") ) { // 普通用户有C权限

  9. result = "ROLE_NORMAL: " + "has CCC permission";

  10. } else {

  11. result = "XXX";

  12. }

  13. return result;

  14. }


  15. }

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

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

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

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


 有枚举为啥不用 

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

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

  1. public interface RoleOperation {

  2. String op(); // 表示某个角色可以做哪些op操作

  3. }

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

  1. public enum RoleEnum implements RoleOperation {


  2. // 系统管理员(有A操作权限)

  3. ROLE_ROOT_ADMIN {

  4. @Override

  5. public String op() {

  6. return "ROLE_ROOT_ADMIN:" + " has AAA permission";

  7. }

  8. },


  9. // 订单管理员(有B操作权限)

  10. ROLE_ORDER_ADMIN {

  11. @Override

  12. public String op() {

  13. return "ROLE_ORDER_ADMIN:" + " has BBB permission";

  14. }

  15. },


  16. // 普通用户(有C操作权限)

  17. ROLE_NORMAL {

  18. @Override

  19. public String op() {

  20. return "ROLE_NORMAL:" + " has CCC permission";

  21. }

  22. };

  23. }

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

  1. public class JudgeRole {

  2. public String judge( String roleName ) {

  3. // 一行代码搞定!之前的if/else没了!

  4. return RoleEnum.valueOf(roleName).op();

  5. }

  6. }

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

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


 有工厂模式为啥不用 

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

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

  1. // 系统管理员(有A操作权限)

  2. public class RootAdminRole implements RoleOperation {


  3. private String roleName;


  4. public RootAdminRole( String roleName ) {

  5. this.roleName = roleName;

  6. }


  7. @Override

  8. public String op() {

  9. return roleName + " has AAA permission";

  10. }

  11. }

  1. // 订单管理员(有B操作权限)

  2. public class OrderAdminRole implements RoleOperation {


  3. private String roleName;


  4. public OrderAdminRole( String roleName ) {

  5. this.roleName = roleName;

  6. }


  7. @Override

  8. public String op() {

  9. return roleName + " has BBB permission";

  10. }

  11. }

  1. // 普通用户(有C操作权限)

  2. public class NormalRole implements RoleOperation {


  3. private String roleName;


  4. public NormalRole( String roleName ) {

  5. this.roleName = roleName;

  6. }


  7. @Override

  8. public String op() {

  9. return roleName + " has CCC permission";

  10. }

  11. }

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

  1. public class RoleFactory {

  2. static Map<String, RoleOperation> roleOperationMap = new HashMap<>();


  3. // 在静态块中先把初始化工作全部做完

  4. static {

  5. roleOperationMap.put( "ROLE_ROOT_ADMIN", new RootAdminRole("ROLE_ROOT_ADMIN") );

  6. roleOperationMap.put( "ROLE_ORDER_ADMIN", new OrderAdminRole("ROLE_ORDER_ADMIN") );

  7. roleOperationMap.put( "ROLE_NORMAL", new NormalRole("ROLE_NORMAL") );

  8. }


  9. public static RoleOperation getOp( String roleName ) {

  10. return roleOperationMap.get( roleName );

  11. }

  12. }

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

  1. public class JudgeRole {

  2. public String judge( String roleName ) {

  3. // 一行代码搞定!之前的 if/else也没了!

  4. return RoleFactory.getOp(roleName).op();

  5. }

  6. }

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

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


 有策略模式为啥不用 

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

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

  1. public class RoleContext {


  2. // 可更换的策略,传入不同的策略对象,业务即相应变化

  3. private RoleOperation operation;


  4. public RoleContext( RoleOperation operation ) {

  5. this.operation = operation;

  6. }


  7. public String execute() {

  8. return operation.op();

  9. }

  10. }

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

  1. public class JudgeRole {

  2. public String judge( RoleOperation roleOperation ) {

  3. RoleContext roleContext = new RoleContext( roleOperation );

  4. return roleContext.execute();

  5. }

  6. }

  1. public static void main( String[] args ) {

  2. JudgeRole judgeRole = new JudgeRole();

  3. String result1 = judgeRole.judge(new RootAdminRole("ROLE_ROOT_ADMIN"));

  4. System.out.println( result1 );

  5. String result2 = judgeRole.judge(new OrderAdminRole("ROLE_ORDER_ADMIN"));

  6. System.out.println( result2 );

  7. String result3 = judgeRole.judge(new NormalRole("ROLE_NORMAL"));

  8. System.out.println( result3 );

  9. }


 共   勉 

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

- END -



更多精彩


在公众号后台对话框输入以下关键词

查看更多优质内容!


女朋友 | 大数据 | 运维 | 书单 | 算法

大数据 | JavaScript | Python | 黑客

AI | 人工智能 | 5G | 区块链

机器学习 | 数学 | 送书

●  人人都欠微软一个正版?

●  脚本之家粉丝福利,请查看!

●  程序员怒打产品经理,这个需求做不了

● 致敬经典:Linux/UNIX必读书单推荐给你

 鲁大师原来真的姓鲁

● 终于有人把 Nginx 说清楚了,图文详解!

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存