本文介绍如何通过 Predicate + Consumer 组合的策略列表替代硬编码的 switch-case，提升代码可扩展性与可测试性，避免 Map 键哈希难题，并提供类型安全、易维护的 Java 实现方案。
本文介绍如何通过 `predicate` + `consumer` 组合的策略列表替代硬编码的 switch-case，提升代码可扩展性与可测试性，避免 map 键哈希难题，并提供类型安全、易维护的 java 实现方案。
在现代 Java 开发中，面对多条件分支逻辑（如根据输入字符串执行不同操作），传统 switch 语句虽简洁，但在需动态注册、运行时扩展或面向接口设计的场景下显得僵化。此时，以策略模式思想构建的函数式分发结构——即用 Predicate
相比直接使用 Map
, Consumer<t>>（如 Map.of(...)），我们<strong>不推荐将 Predicate 作为 Map 的 key</strong>。原因在于：Predicate 是函数式接口，其实例通常为 Lambda 或匿名内部类，其 hashCode() 和 equals() 行为未被明确定义，可能导致查找失败或不可预测行为；同时，Map 的哈希查找在此场景中并无实际优势——我们本质上需要的是“顺序匹配首个满足条件的策略”，而非随机访问。<p>更优解是封装为轻量策略单元。Java 14+ 推荐使用 record 定义不可变策略容器：</p>
<pre class="brush:php;toolbar:false;">record PossibleAction<t>(
Predicate<t> predicate,
Consumer<t> action
) {
public boolean appliesFor(T data) {
return predicate.test(data);
}
public void apply(T data) {
action.accept(data);
}
}</t></t></t>
该设计清晰分离关注点：appliesFor() 封装条件判断逻辑，apply() 封装执行逻辑，且天然支持泛型，保障类型安全。
接着，声明策略列表（支持编译期校验、IDE 自动补全、单元测试独立验证）：
List<possibleaction>> stringActions = List.of(
new PossibleAction(s -> s.contains("A"), s -> System.out.println("Branch A")),
new PossibleAction(s -> s.contains("B") && !s.contains("A"), s -> System.out.println("Branch B")),
new PossibleAction(s -> s.length() > 10, s -> System.out.println("Long string"))
);</possibleaction>
执行时采用流式链式调用，语义明确：
public void route(String input) {
stringActions.stream()
.filter(action -> action.appliesFor(input))
.findFirst() // 匹配首个成功策略（模拟 switch 的 break 语义）
.ifPresentOrElse(
action -> action.apply(input),
() -> System.out.println("No matching branch for: " + input)
);
}
✅ 关键优势总结：
- 可扩展性强：新增分支只需追加 PossibleAction 实例，无需修改原有逻辑；
- 可测试性高：每个 PossibleAction 可独立单元测试，策略列表本身也可作为测试数据源；
- 线程安全：record + 不可变 List.of() 天然不可变，适合在多线程环境共享；
- 无副作用风险：相比 switch 中易遗漏 break 导致的穿透问题，本方案默认单次匹配即终止。
⚠️ 注意事项：
- 若需“匹配全部符合条件的分支”（类似无 break 的 switch），请将 findFirst() 替换为 forEach()；
- 条件顺序敏感，应将高优先级或特异性更强的 Predicate 置于列表前端；
- 对性能极致敏感的高频调用场景，可考虑预编译 Predicate 或引入策略索引缓存，但绝大多数业务场景无需过度优化。
这种函数式策略模式并非要取代所有 switch，而是为复杂、可变、需解耦的分支逻辑提供一种更现代、更工程化的表达方式。
