前两天，有人问我：“项目里有 10000 个 if-else，要怎么优化？” 我听了直接一个头两个大，先别说代码了，光是数数“10000”这个数字，我都怀疑要崩溃了。这要是让我接手，怕不是直接就递辞职信了。
不过仔细一想，这其实是个挺典型的问题。我们写代码，不怕逻辑复杂，就怕代码写得像盘意大利面一样，扯也扯不清。今天咱们就从程序员的角度，聊聊if-else 的优化套路，整点干货！
1. 为什么 10000 个 if-else 是个问题？
10000 个 if-else 你敢想吗？代码看着像这样的：
if (condition1) {
// do something
} else if (condition2) {
// do something else
} else if (condition3) {
// ...
} else if (condition10000) {
// ...
}
这个场景让人崩溃的点主要有以下几个：
- 可维护性低：你敢改，我就敢给你鼓掌。逻辑一改，bug 随时冒出来，还不如从头重写。
- 性能问题：如果条件判断顺序不好，可能需要逐个匹配所有条件，简直就是 CPU 的噩梦。
- 阅读难度爆表：团队协作时，敢看这种代码的人，一定是勇士。
2. 优化套路大放送
2.1 策略模式：化繁为简
策略模式是应对大量 if-else 的经典套路，它的核心是把每个判断条件拆分成独立的策略类。
示例：
假设你在做一个支付系统，不同的支付方式对应不同的逻辑：
// 定义策略接口
public interface PaymentStrategy {
void pay(int amount);
}
// 实现不同策略
public class CreditCardPayment implements PaymentStrategy {
@Override
public void pay(int amount) {
System.out.println("Paid " + amount + " using Credit Card.");
}
}
public class PayPalPayment implements PaymentStrategy {
@Override
public void pay(int amount) {
System.out.println("Paid " + amount + " using PayPal.");
}
}
// 使用策略模式
public class PaymentProcessor {
private Map strategyMap;
public PaymentProcessor() {
strategyMap = new HashMap<>();
strategyMap.put("CREDIT_CARD", new CreditCardPayment());
strategyMap.put("PAYPAL", new PayPalPayment());
}
public void processPayment(String type, int amount) {
PaymentStrategy strategy = strategyMap.get(type);
if (strategy != null) {
strategy.pay(amount);
} else {
throw new IllegalArgumentException("Unsupported payment type: " + type);
}
}
}
这样，新增一种支付方式时，只需要新增一个类，而不是修改原来的 if-else 代码。
2.2 Map 映射：简化条件查找
如果策略模式的类膨胀让你头疼，可以直接用 Map 存储条件和对应逻辑。比如说，一个简单的用户权限处理：
Map actions = new HashMap<>();
actions.put("ADMIN", () -> System.out.println("Welcome Admin!"));
actions.put("USER", () -> System.out.println("Welcome User!"));
actions.put("GUEST", () -> System.out.println("Welcome Guest!"));
// 执行逻辑
String role = "USER";
actions.getOrDefault(role, () -> System.out.println("Role not recognized.")).run();
优点是直接把条件和逻辑分开，维护起来非常轻松。
2.3 使用枚举
如果条件是固定的一组值，比如工作日或颜色，枚举就特别适合：
public enum Day {
MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY, SUNDAY;
}
public String getTaskForDay(Day day) {
switch (day) {
case MONDAY:
return "Start fresh!";
case FRIDAY:
return "Wrap up!";
case SUNDAY:
return "Relax!";
default:
return "Keep going!";
}
}
枚举的优势在于类型安全和可读性，避免了魔法字符串的混乱。
2.4 规则引擎：把逻辑交给专业工具
有些场景，比如复杂的业务规则或者频繁变更的需求，可以直接上规则引擎。像 Java 的 Drools 就是个不错的选择。
示例：
// 定义规则文件 (drl)
rule "Discount for VIP"
when
user.level == "VIP"
then
user.discount = 20;
end
规则引擎的优势是将业务逻辑和代码解耦，非技术人员也能参与规则配置。
2.5 快速返回：别让代码绕圈子
如果可以确定某些条件满足后就不需要再判断后续条件，尽早返回是个好办法：
public String getDiscount(int age) {
if (age < 18 return youth discount if age> 60) return "Senior Discount";
return "No Discount";
}
这种方法简洁直观，尤其在条件优先级明确时特别实用。
2.6 函数式编程：链式调用
现代语言中，函数式编程的灵活性可以让代码更加优雅，比如用 Java 的 Stream：
List roles = Arrays.asList("ADMIN", "USER", "GUEST");
roles.stream()
.filter(role -> role.equals("ADMIN"))
.forEach(role -> System.out.println("Welcome " + role + "!"));
虽然不是万能方法，但在特定场景下确实可以让代码更加清晰。
3. 怎么选？
以上的方法各有优缺点，选择哪个，得看实际业务需求：
- 如果条件固定、数量少：用枚举或者快速返回。
- 如果条件复杂且容易扩展：策略模式或规则引擎更合适。
- 如果需要简单直接：Map 映射和三目运算符不错。
写代码其实和谈恋爱差不多，不同的场景需要不同的套路，咱们得灵活一点。要是真碰到 10000 个 if-else，别慌，慢慢分析逻辑，多用工具，别让自己被代码吓到就好。
最后问一句：你们碰到过最离谱的 if-else 写法是什么样的？欢迎评论区一起吐槽！