函数式接口在 Spring Boot 中使用（模板方法）

目的

了解java8 函数式接口，了解其在企业中的实践

一、企业级 Service 层的痛点

在企业级 Spring Boot 项目中，Service 层往往承担了过多非业务职责：

• 参数校验
• 权限控制
• 日志记录（这边用的）
• 异常包装
• 耗时统计 （这边用的）
• 重试与容错（这边用的）
• 核心业务执行

典型代码如下：

publicvoiddoBusiness(){longstart=System.currentTimeMillis();try{checkParam();checkPermission();doBusinessLogic();}catch(Exceptione){log.error("error",e);throwe;}finally{log.info("cost {} ms",System.currentTimeMillis()-start);}}

你会发现，真正的业务逻辑可能只有一行，却被大量重复模板逻辑包裹。

这并不是开发能力的问题，而是Service 层缺少统一执行模型的必然结果。

二、Java 8 的革命性能力：行为参数化

Java 8 之前：

• 方法只能接收「数据」

Java 8 之后：

• 方法可以接收「行为」

Runnableaction=()->doBusinessLogic();Supplier<Order>supplier=()->queryOrder();

这意味着：

• 可变部分= 业务逻辑
• 稳定部分= 执行流程

这正是模板方法模式的理想落地形式。

三、函数式接口在企业项目中的角色

在企业 Service/Domain 层，高频使用的函数式接口非常有限：

它们的本质非常简单：

() -> void () -> T (T) -> void (T) -> R (T) -> boolean

简单 = 企业级可复用设计的前提

四、函数式接口 = 轻量级策略模式

传统策略模式需要：

• 接口 + 多实现类
• Spring 注入
• 包结构膨胀

对于一次性或少量使用的策略，成本过高。

而函数式接口可以直接用 Lambda 即写即用：

execute("确认订单",()->orderService.confirm(orderId));

• 无额外类
• 无配置成本
• 即写即用

本质上是轻量级策略模式。

五、模板方法核心思想

模板方法的核心：

固定执行流程 + 可插入业务钩子

最简单的形式：

publicfinalclassExecTemplate{publicstaticvoidrun(Stringname,Runnableaction){longstart=System.currentTimeMillis();try{before(name);action.run();after(name);}catch(Exceptione){onError(name,e);throwe;}finally{finallyDo(name,System.currentTimeMillis()-start);}}privatestaticvoidbefore(Stringname){log.info("开始执行：{}",name);}privatestaticvoidafter(Stringname){log.info("执行成功：{}",name);}privatestaticvoidonError(Stringname,Exceptione){log.error("执行失败：{}",name,e);}privatestaticvoidfinallyDo(Stringname,longcost){log.info("{} 耗时 {} ms",name,cost);}}

使用方式：

ExecTemplate.run("确认订单",()->orderService.confirm(orderId));

Service 层完全不再关注重复逻辑，只关心业务“做什么”。

六、企业级“大而全”模板方法示例（Spring Retry 集成）

启用 Spring Retry：

@EnableRetry@ConfigurationpublicclassRetryConfig{}

模板方法：

@Slf4j@ComponentpublicclassExecTemplate{@Retryable(retryFor=Exception.class,maxAttempts=3,backoff=@Backoff(delay=500))public<T>Texecute(Stringname,Supplier<T>supplier){longstart=System.currentTimeMillis();before(name);try{Tresult=supplier.get();after(name);returnresult;}catch(Exceptione){onError(name,e);throwe;}finally{finallyDo(name,System.currentTimeMillis()-start);}}@Retryable(retryFor=Exception.class,maxAttempts=3)publicvoidrun(Stringname,Runnableaction){execute(name,()->{action.run();returnnull;});}protectedvoidbefore(Stringname){log.info("▶ 开始执行：{}",name);}protectedvoidafter(Stringname){log.info("✔ 执行成功：{}",name);}protectedvoidonError(Stringname,Exceptione){log.error("✘ 执行失败：{}",name,e);}protectedvoidfinallyDo(Stringname,longcost){log.info("⏱ {} 耗时 {} ms",name,cost);}@Recoverpublic<T>Trecover(Exceptione,Stringname,Supplier<T>supplier){log.error("‼ {} 重试失败，进入兜底处理",name,e);throwe;}}

七、企业项目中模板方法的典型应用场景

1️⃣ 统一 Service 执行模板

• 统一日志、异常、耗时统计
• Service 方法只关心“做什么”

execTemplate.execute("创建订单",()->orderService.create(cmd));

2️⃣ 远程调用保护模板

• RPC/HTTP/MQ 异常统一处理
• 内置重试、熔断、降级

OrderDTOdto=execTemplate.execute("调用订单中心",()->orderClient.query(orderId));

3️⃣ 缓存加载模板（Cache-Aside）

• 避免重复代码
• 自动处理缓存穿透、空值缓存

Orderorder=cacheTemplate.getOrLoad("order:"+id,()->orderRepository.findById(id));

4️⃣ 幂等执行模板

• 防止重复点击、MQ 重复消费
• 幂等标识 + 并发控制

idempotentTemplate.execute("pay:"+orderId,()->paymentService.pay(orderId));

5️⃣ 状态流转校验模板

• 状态机前置校验
• 提高业务执行安全性

stateTemplate.execute(order.getStatus(),s->s==CREATED,()->order.pay());

6️⃣ 事务包裹模板

• 多步操作统一事务管理
• 避免每个 Service 写@Transactional

transactionTemplate.execute(()->{orderRepo.save(order);inventoryRepo.lock(order);returnorder;});

7️⃣ 数据权限过滤模板

• 查询自动带用户权限
• 避免重复拼接 SQL 或 QueryWrapper

List<Order>orders=permissionTemplate.query(()->orderRepo.findAll());

8️⃣ 规则执行模板

• 统一规则执行框架
• 保证执行流程稳定

rulesTemplate.executeRules(rules,context->apply(context));

八、为什么模板方法优于 AOP

AOP 适合横切关注点
模板方法适合业务执行流程治理

九、设计收益总结

• ✔ Service 层代码高度聚焦业务
• ✔ 执行流程统一可治理
• ✔ 重试、日志、监控集中管理
• ✔ 极低学习成本
• ✔ 易扩展，多业务场景复用

十、一句话总结

函数式接口不是 Stream 的附属品，它是企业级 Service 层模板方法模式的最佳实现载体