函数式接口是策略模式的极简实现形态——将策略从类降维为值,天然适合作为自定义组件中的策略提供者,通过构造/Setter注入、枚举封装、组合扩展等方式实现封装变化、依赖抽象与运行时可插拔。

函数式接口在自定义组件中天然适合作为策略提供者——它把“算法”压缩成一个可传递、可复用、类型安全的函数对象,省去策略模式传统实现中冗余的接口+多个实现类+工厂分发等结构。
用函数式接口替代抽象策略角色
传统策略模式中,Strategy 接口只声明一个方法(如 execute()、apply(T)),这恰好符合函数式接口的定义。因此,无需额外定义空泛的策略接口,直接选用或自定义一个标准函数式接口即可充当策略契约。
- 已有接口优先:比如业务逻辑是「对订单金额做某种计算」,直接用
Function<bigdecimal bigdecimal></bigdecimal>;如果是「校验是否合规」,用Predicate<order></order>更自然 - 自定义时加
@FunctionalInterface注解,确保编译期约束(如DiscountCalculator extends Function<order bigdecimal></order>) - 避免为单方法再包一层无意义的接口,例如不要写
interface PriceStrategy { BigDecimal calc(Order o); },而应直接使用Function<order bigdecimal></order>
组件内通过构造/Setter注入策略行为
自定义组件(如 OrderProcessor、NotificationSender)不持有具体实现类,而是持有一个函数式接口类型的字段,运行时由外部注入具体逻辑。
- 构造注入示例:
private final Function<order string> orderFormatter;</order>,创建组件时传入o -> "[" + o.getId() + "] " + o.getDesc() - Setter 或 Builder 方式也适用,便于测试替换(如单元测试中注入返回固定字符串的 lambda)
- 组件内部调用
orderFormatter.apply(order),完全解耦算法细节
结合枚举实现静态策略集(轻量级策略注册表)
当策略种类固定、数量有限(如支付方式:ALIPAY、WECHAT、CARD),可用枚举实现函数式接口,每个枚举项封装独立行为,兼具类型安全与可读性。
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
立即学习“Java免费学习笔记(深入)”;
- 枚举直接
implements Function<order paymentresult></order>,构造器接收 lambda 或方法引用 - 调用时用
PayMethod.WECHAT.apply(order),比 if-else 或 Map 查找更简洁、无 NPE 风险 - 支持序列化(配合
@JsonValue)、IDE 自动补全、编译期校验新增策略
利用组合能力构建复合策略
函数式接口原生支持链式组合,让策略具备扩展性,无需修改组件代码就能叠加新逻辑。
-
Function的andThen()和compose()可串接预处理与后处理:如先格式化再加水印 -
Predicate的and()/or()/negate()能动态拼装校验规则:如notExpired.and(isActive).or(isAdmin) - 组件只需声明接受一个
Predicate<t></t>,调用方决定组合粒度
本质上,函数式接口不是策略模式的“替代品”,而是它的极简实现形态——把策略从类的层级降维到值的层级,让策略真正变成一等公民。只要组件面向函数式接口编程,就已悄然落地了策略模式的核心思想:封装变化、依赖抽象、运行时可插拔。

















