Java if-else 多重嵌套的优化方式

目录

• if-else多重嵌套的优化
• 1. if-else 多重嵌套的问题
• 2. 解决方案
• 2.1 使用Map缓存
• 2.2 switch 简化条件
• 多个ifelse语句的替代设计
• 案例研究
• 重构
• 工厂模式
• 使用枚举
• 命令模式
• 规则引擎
• 小结

if-else多重嵌套的优化

1. if-else 多重嵌套的问题

项目重构发现代码中存在类似以下的三重 if-else 嵌套代码，其中变量 a、b、c有三种可能的取值，组合起来共有27 个分支，这还没有算上对各个变量进行合法性校验失败的分支。

如此繁杂琐碎的代码阅读起来有多费劲可想而知，而条件判断太多对理解业务逻辑也是个问题，更不用提之后的扩展维护

if (a == 1) {
    if (b == 1) {
        if (c == 1) {
        } else if (c == 2) {
        } else if (c == 3) {
        } else {
        }
    } else if (b == 2) {
    }
    ......
} else if (a == 2) {
  ......
}

2. 解决方案

条件判断嵌套过多的害处毋庸多言，仔细思索后大致整理了优化思路，首要点是将多重条件判断进行整合。如以上例子中对 3 个变量的取值逐一判断来确定一条分支其实可以优化为以 3 个变量聚合为一个条件进行分支确定，这样分支数并不会减少，但是对条件的判断必然是更为清晰的

2.1 使用Map缓存

基于以上例子，变量 a、b、c都是整数类型的数据，则可以考虑将其合并为一个String 数据，以字符串"111" 来表示 a=1, b=1, c=1 的条件，这样可以用一个 Map 结构来存储对应操作标识，从而实现策略切换。这种方式通常会另外新建一个工具类，通过工具类来获取对应条件的结果

public static Map<String, MatchVerifyResultDTO> getInstance() {
        if (upCreditMap.isEmpty()) {
            MatchVerifyResultDTO invalidResult = new MatchVerifyResultDTO(false,
                    MatchVerifyEnum.MVC_UP_CREDIT_ERR.getCode());
            MatchVerifyResultDTO validResult = new MatchVerifyResultDTO(true, MatchVerifyEnum.MVC_PASS.getCode());
            upCreditMap.put("111", invalidResult);
            upCreditMap.put("112", validResult);
            upCreditMap.put("113", validResult);
          ......
        }
        return upCreditMap;
    }

2.2 switch 简化条件

如果不准备新建工具类来实现条件简化，也可以采用 switch结构。不过不管何种方式，核心思想是不变的，即采用整体数据来消弭小的差异判断，此处依然将变量 a、b、c合并为一个String 特征条件

switch(attribute) {
     case "111":
     case "112":
         handleTargetMessage();
         break;
     ......
     default:
         log.error("Not supported attribute!")
           break;
}

多个ifelse语句的替代设计

ifelse是任何编程语言的重要组成部分。但是我们编写了大量嵌套的if语句，这使得我们的代码更加复杂和难以维护。

接下来，让我们探索如何简化代码的中的ifelse语句写法。

案例研究

我们经常遇到涉及很多条件的业务逻辑，并且每个逻辑都需要不同的处理方式。以Calculator类为例。我们将有一个方法，它接受两个数字和一个运算符作为输入，并根据操作返回结果：

public int calculate(int a, int b, String operator) {
    int result = Integer.MIN_VALUE; 
    if ("add".equals(operator)) {
        result = a + b;
    } else if ("multiply".equals(operator)) {
        result = a * b;
    } else if ("divide".equals(operator)) {
        result = a / b;
    } else if ("subtract".equals(operator)) {
        result = a - b;
    }
    return result;
}

我们也可以使用switch语句来实现它：

public int calculateUsingSwitch(int a, int b, String operator) {
    switch (operator) {
    case "add":
        result = a + b;
        break;
    // other cases    
    }
    return result;
}

在典型的开发中，if语句可能会变得更大，更复杂。此外，当存在复杂条件时，switch语句不适合。

拥有嵌套决策结构的另一个副作用是它们变得难以管理。例如，如果我们需要添加一个新的运算符，我们必须添加一个新的if语句并实现该操作。

重构

可以通过设计模式，来达到我们要的效果。

工厂模式

很多时候，我们遇到ifelse结构，最终在每个分支中执行类似的操作。这提供了提取工厂方法的机会，该工厂方法返回给定类型的对象并基于具体对象行为执行操作。

对于我们的示例，让我们定义一个具有单个apply方法的Operation接口：

public interface Operation {
    int apply(int a, int b);
}

该方法将两个数字作为输入并返回结果。让我们定义一个用于执行添加的类：

public class Addition implements Operation {
    @Override
    public int apply(int a, int b) {
        return a + b;
    }
}

我们现在将实现一个工厂类，它根据给定的运算符返回Operation的实例：

public class OperatorFactory {
    static Map<String, Operation> operationMap = new HashMap<>();
    static {
        operationMap.put("add", new Addition());
        operationMap.put("divide", new Division());
        // more operators
    } 
    public static Optional<Operation> getOperation(String operator) {
        return Optional.ofNullable(operationMap.get(operator));
    }
}

现在，在Calculator类中，我们可以查询工厂以获取相关操作并应用源数：

public int calculateUsingFactory(int a, int b, String operator) {
    Operation targetOperation = OperatorFactory
      .getOperation(operator)
      .orElseThrow(() -> new IllegalArgumentException("Invalid Operator"));
    return targetOperation.apply(a, b);
}

在这个例子中，我们已经看到了如何将责任委托给工厂类提供的松散耦合对象。但是有可能嵌套的if语句只是转移到了工厂类，这违背了我们的目的。

或者，我们可以在Map中维护一个对象存储库，可以查询该存储库以进行快速查找。正如我们所见，OperatorFactory＃operationMap服务于我们的目的。我们还可以在运行时初始化Map并将它们配置为查找。

使用枚举

除了使用Map之外，我们还可以使用Enum来标记特定的业务逻辑。之后，我们可以在嵌套的if语句或switch case 语句中使用它们。或者，我们也可以将它们用作对象的工厂并制定策略以执行相关的业务逻辑。

这样可以减少嵌套if语句的数量，并将责任委托给单个Enum值。

让我们看看我们如何实现它。首先，我们需要定义我们的枚举：

public enum Operator {
    ADD, MULTIPLY, SUBTRACT, DIVIDE
}

可以观察到，这些值是不同运算符的标签，将进一步用于计算。我们总是可以选择在嵌套的if语句或switch case中使用这些值作为不同的条件，但让我们设计一种将逻辑委托给Enum本身的替代方法。

我们将为每个Enum值定义方法并进行计算。例如：

ADD {
    @Override
    public int apply(int a, int b) {
        return a + b;
    }
},
// other operators 
public abstract int apply(int a, int b);

然后在Calculator类中，我们可以定义一个执行操作的方法：

public int calculate(int a, int b, Operator operator) { return operator.apply(a, b); }

现在，我们可以通过使用Operator＃valueOf()方法将String值转换为Operator来调用该方法：

@Test
public void test() {
    Calculator calculator = new Calculator();
    int result = calculator.calculate(3, 4, Operator.valueOf("ADD"));
    assertEquals(7, result);
}

命令模式

在前面的讨论中，我们已经看到使用工厂类来返回给定运算符的正确业务对象的实例。稍后，业务对象用于在计算器中执行计算。

我们还可以设计一个Calculator＃calculate方法来接受可以在输入上执行的命令。这将是替换嵌套if语句的另一种方法。

我们首先定义我们的Command接口：

public interface Command {
    Integer execute();
}

接下来，让我们实现一个AddCommand：

public class AddCommand implements Command {
    // Instance variables
 
    public AddCommand(int a, int b) {
        this.a = a;
        this.b = b;
    } 
    @Override
    public Integer execute() {
        return a + b;
    }
}

最后，让我们在Calculator中引入一个接受并执行Command的新方法：

public int calculate(Command command) {
    return command.execute();
}

接下来，我们可以通过实例化AddCommand调用计算并将其发送到Calculator＃calculate方法：

@Test
public void test() {
    Calculator calculator = new Calculator();
    int result = calculator.calculate(new AddCommand(3, 7));
    assertEquals(10, result);
}

规则引擎

当我们最终编写大量嵌套if语句时，每个条件都描述了一个业务规则，必须对其进行评估才能处理正确的逻辑。规则引擎从主代码中获取了这种复杂性。一个RuleEngine评估规则和返回基于输入的结果。

让我们通过设计一个简单的RuleEngine来演示一个例子，该RuleEngine通过一组规则处理Expression并返回所选规则的结果。首先，我们将定义一个Rule接口：

public interface Rule {
    boolean evaluate(Expression expression);
    Result getResult();
}

其次，让我们实现一个RuleEngine：

public class RuleEngine {
    private static List<Rule> rules = new ArrayList<>(); 
    static {
        rules.add(new AddRule());
    } 
    public Result process(Expression expression) {
        Rule rule = rules
          .stream()
          .filter(r -> r.evaluate(expression))
          .findFirst()
          .orElseThrow(() -> new IllegalArgumentException("Expression does not matches any Rule"));
        return rule.getResult();
    }
}

所述RuleEngine接受一个表达对象，并返回结果。现在，让我们将Expression类设计为一组包含两个Integer对象的Operator，它将被应用：

public class Expression {
    private Integer x;
    private Integer y;
    private Operator operator;        
}

最后让我们定义一个自定义的AddRule类，该类仅在指定ADD操作时进行求值：

public class AddRule implements Rule {
    @Override
    public boolean evaluate(Expression expression) {
        boolean evalResult = false;
        if (expression.getOperator() == Operator.ADD) {
            this.result = expression.getX() + expression.getY();
            evalResult = true;
        }
        return evalResult;
    }    
}

我们现在将使用Expression调用RuleEngine：

@Test
public void test() {
    Expression expression = new Expression(5, 5, Operator.ADD);
    RuleEngine engine = new RuleEngine();
    Result result = engine.process(expression); 
    assertNotNull(result);
    assertEquals(10, result.getValue());
}

小结

通过这些设计模式，可以作为我们的ifelse语句的替代方案，具体用哪一种可以根据你的实际业务场景来决定。

以上为个人经验，希望能给大家一个参考，也希望大家多多支持我们。