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

来源：CodeSheep

作者：hansonwong99

 哎，曾几何时 

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

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

• 系统管理员（ ROLE_ROOT_ADMIN）：有 A操作权限
• 订单管理员（ ROLE_ORDER_ADMIN）：有 B操作权限

• 普通用户（ ROLE_NORMAL）：有 C操作权限

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

1. publicclassJudgeRole{

2. 
   

3. publicString judge( String roleName ) {

4. String result = "";

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

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

7. } elseif( roleName.equals("ROLE_ORDER_ADMIN") ) { // 订单管理员有B权限

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

9. } elseif( roleName.equals("ROLE_NORMAL") ) { // 普通用户有C权限

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

11. } else{

12. result = "XXX";

13. }

14. return result;

15. }

16. 
    

17. }

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

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

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

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

---

 有枚举为啥不用 

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

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

1. publicinterfaceRoleOperation{

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

3. }

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

1. publicenumRoleEnumimplementsRoleOperation{

2. 
   

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

4. ROLE_ROOT_ADMIN {

5. @Override

6. publicString op() {

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

8. }

9. },

10. 
    

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

12. ROLE_ORDER_ADMIN {

13. @Override

14. publicString op() {

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

16. }

17. },

18. 
    

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

20. ROLE_NORMAL {

21. @Override

22. publicString op() {

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

24. }

25. };

26. }

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

1. publicclassJudgeRole{

2. publicString judge( String roleName ) {

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

4. returnRoleEnum.valueOf(roleName).op();

5. }

6. }

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

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

---

 有工厂模式为啥不用 

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

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

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

2. publicclassRootAdminRoleimplementsRoleOperation{

3. 
   

4. privateString roleName;

5. 
   

6. publicRootAdminRole( String roleName ) {

7. this.roleName = roleName;

8. }

9. 
   

10. @Override

11. publicString op() {

12. return roleName + " has AAA permission";

13. }

14. }

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

2. publicclassOrderAdminRoleimplementsRoleOperation{

3. 
   

4. privateString roleName;

5. 
   

6. publicOrderAdminRole( String roleName ) {

7. this.roleName = roleName;

8. }

9. 
   

10. @Override

11. publicString op() {

12. return roleName + " has BBB permission";

13. }

14. }

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

2. publicclassNormalRoleimplementsRoleOperation{

3. 
   

4. privateString roleName;

5. 
   

6. publicNormalRole( String roleName ) {

7. this.roleName = roleName;

8. }

9. 
   

10. @Override

11. publicString op() {

12. return roleName + " has CCC permission";

13. }

14. }

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

1. publicclassRoleFactory{

2. staticMap<String, RoleOperation> roleOperationMap = newHashMap<>();

3. 
   

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

5. static{

6. roleOperationMap.put( "ROLE_ROOT_ADMIN", newRootAdminRole("ROLE_ROOT_ADMIN") );

7. roleOperationMap.put( "ROLE_ORDER_ADMIN", newOrderAdminRole("ROLE_ORDER_ADMIN") );

8. roleOperationMap.put( "ROLE_NORMAL", newNormalRole("ROLE_NORMAL") );

9. }

10. 
    

11. publicstaticRoleOperation getOp( String roleName ) {

12. return roleOperationMap.get( roleName );

13. }

14. }

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

1. publicclassJudgeRole{

2. publicString judge( String roleName ) {

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

4. returnRoleFactory.getOp(roleName).op();

5. }

6. }

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

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

---

 有策略模式为啥不用 

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

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

1. publicclassRoleContext{

2. 
   

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

4. privateRoleOperation operation;

5. 
   

6. publicRoleContext( RoleOperation operation ) {

7. this.operation = operation;

8. }

9. 
   

10. publicString execute() {

11. return operation.op();

12. }

13. }

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

1. publicclassJudgeRole{

2. publicString judge( RoleOperation roleOperation ) {

3. RoleContext roleContext = newRoleContext( roleOperation );

4. return roleContext.execute();

5. }

6. }

1. publicstaticvoid main( String[] args ) {

2. JudgeRole judgeRole = newJudgeRole();

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

4. System.out.println( result1 );

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

6. System.out.println( result2 );

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

8. System.out.println( result3 );

9. }

---

 共   勉 

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

推荐阅读

全部文章分类与整理（算法+数据结构+计算机基础），持续更新

【吐血整理】那些让你起飞的计算机基础知识：学什么，怎么学？

普普通通，我的三年大学

写公众号15个月以来，这一路上的学习与收获

历经两个月，我的秋招之路结束了！

2020 第一篇原创 | 我是如何让自己变的更加优秀的？