代码重构实战：5种if/else优化技巧提升可读性

相信很多工程师都有同感，当代码中充满了复杂的if-else嵌套时，不仅阅读起来费劲，后期的维护成本也会急剧升高，很容易引入Bug。当然，对于如何优化，也存在不同的看法。

观点一：系统性重构策略

随着需求的不断迭代，如果只是简单地“来一个需求，加一个if”，代码最终会变成一座难以维护的“金字塔”。

!图片：代码金字塔示意图

当代码复杂到难以维护时，就必须下决心重构。那么，有哪些方案可以优雅地优化掉这些冗余的if/else呢？

1. 提前 Return (条件取反)

这是通过反转判断逻辑来减少嵌套的经典方法，能让代码的逻辑流更清晰。先看常见的写法：

if (condition) {
    // do something
} else {
    return xxx;
}

每次看到这种结构，其实都可以通过先判断否定条件来消除else：

if (!condition) {
    return xxx;
}
// do something (原if块内的逻辑)

2. 策略模式

根据不同的参数或策略执行不同的逻辑，是if-else泛滥的重灾区。典型实现如下：

if (strategy.equals("fast")) {
    // 快速执行
} else if (strategy.equals("normal")) {
    // 正常执行
} else if (strategy.equals("smooth")) {
    // 平滑执行
} else if (strategy.equals("slow")) {
    // 慢速执行
}

面对这种多分支场景，有两种优雅的优化方案。

2.1 多态与Map映射 定义一个策略接口和一系列实现类：

interface Strategy {
    void run() throws Exception;
}

class FastStrategy implements Strategy {
    @Override
    void run() throws Exception {
        // 快速执行逻辑
    }
}
// ... 其他策略类 NormalStrategy, SmoothStrategy, SlowStrategy

然后利用Map来管理和获取策略对象：

// 初始化策略Map (可通过Spring等IoC容器注入)
Map<String, Strategy> strategyMap = new HashMap<>();
strategyMap.put("fast", new FastStrategy());
// ...

// 使用时的调用变得非常简洁
Strategy strategy = strategyMap.get(param);
strategy.run();

这种方案的缺点是，每新增一个策略，都需要手动将其注册到Map中，容易遗漏。

2.2 枚举策略 许多人忽略了Java枚举可以定义抽象方法这一强大特性。我们可以直接定义一个策略枚举：

public enum Strategy {
    FAST {
        @Override
        void run() {
            //do something
        }
    },
    NORMAL {
        @Override
        void run() {
            //do something
        }
    },
    SMOOTH {
        @Override
        void run() {
            //do something
        }
    },
    SLOW {
        @Override
        void run() {
            //do something
        }
    };
    abstract void run();
}

优化后的调用代码极其清晰：

Strategy strategy = Strategy.valueOf(param.toUpperCase()); // 注意参数转换
strategy.run();

3. 善用 Optional 进行非空判断

Optional是Java 8引入的用于优雅处理NullPointerException的工具，可以有效减少显式的if (obj == null)判断。

优化前：

if (user == null) {
    //do action 1
} else {
    //do action 2
}

使用Optional优化后，逻辑表达更直接：

Optional<User> userOptional = Optional.ofNullable(user);
userOptional.map(action1).orElse(action2);

4. 表驱动法（数组/Map查询）

这是一种用表（数组、Map）查询信息来代替复杂逻辑语句的编程模式。例如，根据月份获取天数（数据仅为演示）：

传统if-else实现：

int getDays(int month){
    if (month == 1) return 31;
    if (month == 2) return 29;
    if (month == 3) return 31;
    // ... 冗长的判断直到12月
}

使用表驱动法优化后：

int[] monthDays = {31, 29, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31};
int getDays(int month){
    return monthDays[--month]; // 注意月份与数组索引的转换
}

观点二：关注语义而非层数

另一种观点认为，不应过度关注if/else的层数本身，而应关注接口的语义是否足够清晰。单纯为了减少层数而拆出一堆do_logic1()、do_logic2()这样的方法，往往于事无补。

一个接口的执行可归纳为：输入 + 内部状态 -> 输出。优化需要针对不同情况：

• 逻辑本身复杂：例如经过精细优化的数值计算，需根据不同输入范围采取多种策略。此时if/else多难以避免。重点应通过详细文档和代码注释，确保语义清晰。
• 输入过于复杂：如接口参数包含大量标记位(flag)。此时问题在于抽象层次不足。应拆分接口，或使用Adapter模式封装参数与分支逻辑。
• 输出过于复杂：一个方法计算并返回了太多内容。应果断拆分为多个职责单一的方法，共用计算部分可提取为私有方法或通过缓存对象共享。
• 内部状态过于复杂：首先检查状态设计是否合理，是否应作为输入参数；其次尝试对状态分组管理；最后可画出状态转移图，用单层分派（如Switch或查找表）调用对应的状态处理方法。

真正的优化往往源于对整体接口抽象的重新思考，而非孤立地处理某个方法里的分支语句。