利用 Function 接口告别冗余（屎山）代码，优雅到不像 Java-优快云博客

告别 if-else 地狱，从函数式优雅起步！
Function、Consumer、Map、枚举策略模式，一文带你从逻辑屎山中解脱出来！👋

🧭 前言

说起用 Function 接口优化代码，兄弟们，我脑子里第一个浮现的画面就是：

满屏 if-else、switch-case，一整个“判断地狱”🌀。

每次看到这种逻辑，我都想给作者寄刀片 ✂️，维护起来比谈恋爱还难。

🧱 一、屎山现场：经典 if-else 地狱

以前做“用户行为打标签”，十几个类型，每个行为都对应一段处理逻辑，原来是这样的：

if ("LOGIN".equals(type)) {
    handleLogin(user);
} else if ("PURCHASE".equals(type)) {
    handlePurchase(user);
} else if ("SHARE".equals(type)) {
    handleShare(user);
}
// ...一大片 else if

增加逻辑要往下翻一大堆；
改动一点，还得担心动到其他逻辑；
测试难、维护难、扩展更难……

这就是典型的屎山代码，简直想退圈种地去🌿。

🚀 二、Function + Map，优雅实现逻辑映射

后来我觉醒了！用了 Java 8 的 Consumer 接口 + 策略模式优化，一下清爽了：

Map<String, Consumer<User>> strategyMap = new HashMap<>();
strategyMap.put("LOGIN", this::handleLogin);
strategyMap.put("PURCHASE", this::handlePurchase);
strategyMap.put("SHARE", this::handleShare);

Optional.ofNullable(strategyMap.get(type))
        .ifPresent(action -> action.accept(user));

这玩意简直就是：

给屎山刮了层皮，还喷了点香水💐。

✅ 结构清晰
✅ 扩展方便
✅ 新增逻辑不用动老代码

新增处理逻辑只需要一行：

strategyMap.put("COMMENT", this::handleComment);

🧪 三、需要返回值？用 Function<T, R>

如果你还要处理返回结果，用 Function<T, R> 更合适：

Map<String, Function<User, String>> strategyMap = new HashMap<>();
strategyMap.put("LOGIN", this::processLogin);
strategyMap.put("PURCHASE", this::processPurchase);

String result = strategyMap
    .getOrDefault(type, u -> "未知类型")
    .apply(user);

一句话：行为映射成数据，逻辑变得利索又解耦。

💡 四、策略进阶版：枚举 + Lambda

Map 太多担心性能？那就上更优雅的 枚举式策略模式：

public enum ActionType {
    LOGIN(user -> "处理登录"),
    PURCHASE(user -> "处理购买");

    private final Function<User, String> action;

    ActionType(Function<User, String> action) {
        this.action = action;
    }

    public String execute(User user) {
        return action.apply(user);
    }
}

调用方式：

String result = ActionType.valueOf(type).execute(user);

说实话：优雅得不像 Java 👑。

🪤 五、现实血泪史：数据清洗模块的 Switch 地狱

我还见过更离谱的：

一个类几百行 switch-case，每个 case 只有两行逻辑。
只为更新某个字段，却硬是手撸了上百个 case 分支 🤯。

本来一个 Map 就能搞定的事，非要搞成手写地狱图谱……

⚠️ 六、一些使用建议

Map 查找是 O(1)，性能不是问题，别滥用全局可变 Map；
若逻辑可组合/可配置，Function 很适合；
若逻辑只有两个分支，别搞过度设计；
若逻辑有状态切换、依赖上下文，可以考虑 BiFunction 或策略类配合使用；
枚举方式更加稳健、结构清晰、无魔法字符串问题。

🎯 七、总结

用好 Function 接口的本质是：函数式思维 + 行为抽象 = 结构更清晰的代码。

技术没有银弹，但屎山能不踩就不踩。
你早晚要面对维护的地狱，不如提前重构。

别怕麻烦，该推就推；别怕重构，否则最后吃苦的是自己。

💬 尾声

我个人非常推荐在这类 “类型到行为” 的映射场景中使用 Function。

它就像程序员的调味料：

🧂用得妙，代码香气扑鼻；
🧟乱放，就是黑暗料理。

兄弟们你们有用过类似技巧吗？欢迎在评论区分享你遇到的屎山场景，咱们一起来扒一扒，还有哪些屎山值得优化 😏