
本文探讨了如何通过java函数式接口和参数绑定技术,通用化处理不同参数数量的feign分页api调用。通过引入泛型接口和静态工厂方法,我们能够将多参数的api调用统一抽象为仅需页码和大小的接口,从而大幅减少重复代码,提升代码的可维护性和可读性,并优化了分页数据抽取逻辑。
1. 问题背景与挑战
在实际项目开发中,我们经常需要调用各种分页API来获取大量数据。当使用Feign客户端调用这些API时,通常会面临以下挑战:
- 参数数量不一: 不同的Feign API可能需要不同数量的业务参数,但它们的共同点是最后两个参数通常是页码(page)和页面大小(size)。
-
数据结构相似但核心数据类型不同: 返回的分页数据结构(如包含总页数、总条数等)通常是相似的,但实际的核心数据列表类型(例如List
、List ail>)会因API而异。 - 重复代码: 如果为每个具有不同业务参数的Feign API都编写一套独立的分页调用和数据抽取逻辑,会导致大量的重复代码,降低开发效率和代码可维护性。
原始的解决方案尝试通过定义特定的接口(如SingleParamPagingApi)和实现类(如SingleParamPageableCall)来处理具有特定参数数量的API。例如:
public interface SingleParamPagingApi{ ResponseEntity > callFeignApi(String arg, int page, int size) throws RuntimeException; } public static class SingleParamPageableCall implements PagedCall { SingleParamPagingApi fun; String param; public SingleParamPageableCall(SingleParamPagingApi fun, String param) { this.fun = fun; this.param = param; } @Override public BaseFeignResult call(int p, int s) { BaseFeignResult.BaseFeignResultBuilder builder = BaseFeignResult.builder(); try { builder.resp(fun.callFeignApi(param, p, s)); } catch (RuntimeException e) { builder.excp(e); } return builder.build(); } }
这种方法虽然可行,但每当遇到不同数量参数的API时,都需要创建新的XParamPagingApi接口和XParamPageableCall实现类,导致了繁琐的模板代码。我们的目标是找到一种更具描述性、更函数式的方式来解决这个问题,避免这种“重型对象”的定义。
2. 解决方案:基于函数式接口的参数绑定
为了解决上述问题,我们可以利用Java 8的函数式接口特性,通过参数绑定(或称为局部应用/柯里化)将多参数的API调用统一抽象为仅接受页码和页面大小的接口。
立即学习“Java免费学习笔记(深入)”;
2.1 核心接口定义
首先,我们定义针对不同参数数量的原始API函数式接口,以及一个统一的、仅接受页码和页面大小的PagingApi接口:
// 泛型接口:用于描述具有一个业务参数的Feign分页API public interface PagingApi1{ ResponseEntity > callFeignApi(A0 arg0, int page, int size) throws RuntimeException; } // 泛型接口:用于描述具有两个业务参数的Feign分页API public interface PagingApi2 { ResponseEntity > callFeignApi(A0 arg0, A1 arg1, int page, int size) throws RuntimeException; } // ... 可以根据需要定义 PagingApi3, PagingApi4 等 // 统一的PagingApi接口:只关注页码和页面大小 public interface PagingApi { // 静态工厂方法:将一个业务参数的API绑定到统一接口 static PagingApi of(PagingApi1 api, A0 arg0) { return (p, s) -> api.callFeignApi(arg0, p, s); } // 静态工厂方法:将两个业务参数的API绑定到统一接口 static PagingApi of(PagingApi2 api, A0 arg0, A1 arg1) { return (p, s) -> api.callFeignApi(arg0, arg1, p, s); } // 核心方法:统一的API调用接口,只接受页码和页面大小 ResponseEntity > callFeignApi(int page, int size) throws RuntimeException; }
在上述代码中:
- PagingApi1
和PagingApi2 等接口用于描述原始的Feign方法签名,其中A0, A1是业务参数类型。 - PagingApi
是核心抽象,它定义了一个只接受页码和页面大小的callFeignApi方法。 - PagingApi中的static of方法是关键。它们接收一个具体参数数量的PagingApiX实例和对应的业务参数,并返回一个PagingApi实例。这意味着我们通过lambda表达式将业务参数“绑定”到原始方法上,从而生成了一个新的函数,这个新函数只等待页码和页面大小。
2.2 通用化的分页调用封装
接下来,我们修改PagedCall的实现类,使其能够接受这个统一的PagingApi接口:
// PagedCall 接口保持不变 public interface PagedCall{ BaseFeignResult call(int p, int s); } // 通用化的 PageableCall 实现 public static class PageableCall implements PagedCall { PagingApi fun; // 现在接受统一的 PagingApi 接口 public PageableCall(PagingApi fun) { this.fun = fun; } @Override public BaseFeignResult call(int p, int s) { BaseFeignResult.BaseFeignResultBuilder builder = BaseFeignResult.builder(); try { builder.resp(fun.callFeignApi(p, s)); // 调用统一接口的方法 } catch (RuntimeException e) { builder.excp(e); } return builder.build(); } } // BaseFeignResult 和 IVDPagedResponseOf 保持不变,用于封装响应和异常 @Builder public static class BaseFeignResult { private final ResponseEntity > resp; private final RuntimeException excp; }
现在,PageableCall不再需要关心底层Feign API有多少个业务参数,它只知道如何调用一个抽象的、接受页码和页面大小的PagingApi。
2.3 示例调用
通过上述改造,调用方代码将变得极其简洁和富有表现力:
假设 ordersFeignClient 是一个 Feign 客户端,其中包含方法 getOrdersBySampleIds(String sampleId, int page, int size)。
// 原始的 Feign 客户端方法引用 // ordersFeignClient::getOrdersBySampleIds 对应 PagingApi1drainFeignPageableCall( new PageableCall ( // 使用 PagingApi.of 绑定业务参数 "34596",生成一个 PagingApi 实例 PagingApi.of(ordersFeignClient::getOrdersBySampleIds, "34596") ) );
现在,无论ordersFeignClient中的方法有多少个业务参数,我们都可以通过PagingApi.of方法将其“适配”成一个统一的PagingApi实例,然后传递给PageableCall。这极大地减少了为每个API编写重复抽象的需要。
3. 分页数据抽取逻辑优化
原始的drainFeignPageableCall方法使用了递归实现。虽然递归在某些场景下具有函数式风格,但在处理大量分页数据时,可能会导致栈溢出(StackOverflowError),并且通常不如迭代(循环)效率高。建议将其重构为迭代方式。
3.1 原始递归实现(作为对比)
publicList > drainFeignPageableCall(PagedCall feignCall) { BaseFeignResult firstPage = feignCall.call(0, 10); List > baseFeignResults = Lists.newArrayList(firstPage); // 使用 Guava 的 Lists.newArrayList // 注意:原始的停止条件 `data.size() % 10 > 0` 存在潜在问题,如果最后一页恰好是满页,会提前停止。 // 更健壮的停止条件通常是 `data.size() < pageSize` 或基于响应中的 totalElements/totalPages。 if (firstPage.resp != null && firstPage.resp.getBody() != null && firstPage.resp.getBody().getData() != null && firstPage.resp.getBody().getData().size() < 10) { // 如果第一页不满,则只有一页 return baseFeignResults; } return drainFeignPageableCall(feignCall, firstPage, baseFeignResults, 1); } List > drainFeignPageableCall( PagedCall feignCall, BaseFeignResult dataPage, List > acc, int page ) { if (dataPage.resp.getBody().getData().size() % 10 > 0) // 停止条件 return acc; BaseFeignResult res = feignCall.call(page, 10); acc.add(res); return drainFeignPageableCall(feignCall, res, acc, ++page); }
3.2 推荐的迭代实现
一个更健壮且高效的迭代版本应该明确地处理页码递增和停止条件,并考虑错误处理。
import java.util.ArrayList; import java.util.List; publicList > drainFeignPageableCallIterative(PagedCall feignCall, int initialPageSize) { List > allPagesResults = new ArrayList<>(); int currentPage = 0; int pageSize = initialPageSize; // 页面大小可以作为参数传入 while (true) { BaseFeignResult currentResult = feignCall.call(currentPage, pageSize); allPagesResults.add(currentResult); // 优先检查是否有异常 if (currentResult.excp != null) { System.err.println("Error draining page " + currentPage + ": " + currentResult.excp.getMessage()); // 根据业务需求决定是中断、记录日志还是重新抛出 break; } // 检查响应体和数据列表是否有效 if (currentResult.resp == null || currentResult.resp.getBody() == null || currentResult.resp.getBody().getData() == null) { System.err.println("Received null response body or data for page " + currentPage); break; // 无效响应,停止 } // 获取当前页的数据列表 List dataList = currentResult.resp.getBody().getData(); // 停止条件:如果当前页返回的数据量小于请求的页面大小,则说明已是最后一页 // 或者如果返回数据量为0,也表示没有更多数据 if (dataList.size() < pageSize) { break; // 已到达最后一页 } currentPage++; // 继续请求下一页 } return allPagesResults; }
注意事项:
- 停止条件: 迭代实现中的停止条件dataList.size()
- 错误处理: 在循环中加入异常检查,确保即使某个分页请求失败,也能优雅地处理或停止。
- 页面大小: pageSize可以作为参数传入,增加灵活性。
4. 进一步简化:合并接口
如答案中建议,PagingApi和PagedCall这两个接口在功能上存在重叠,可以考虑将其合并为一个接口,进一步简化设计。
// 合并后的接口 public interface UnifiedPageableApi{ // 静态工厂方法与 PagingApi 类似 static UnifiedPageableApi of(PagingApi1 api, A0 arg0) { return (p, s) -> { BaseFeignResult.BaseFeignResultBuilder builder = BaseFeignResult.builder(); try { builder.resp(api.callFeignApi(arg0, p, s)); } catch (RuntimeException e) { builder.excp(e); } return builder.build(); }; } // 其他 of 方法... // 核心方法:直接返回 BaseFeignResult BaseFeignResult call(int p, int s); } // 此时 drainFeignPageableCallIterative 可以直接接受 UnifiedPageableApi public List > drainFeignPageableCallIterative(UnifiedPageableApi api, int initialPageSize) { // ... 内部逻辑与之前 PagedCall 版本的 drain 方法类似,直接调用 api.call(currentPage, pageSize) }
这种合并减少了一个抽象层,使得代码更加紧凑。
5. 总结
通过引入PagingApi系列函数式接口和static of工厂方法,我们成功地将Feign分页API的参数绑定逻辑从具体的调用实现中解耦出来。这种方法具有以下优点:
- 减少重复代码: 避免为每个不同参数数量的API重复定义接口和类。
- 提高可维护性: 核心逻辑集中在PagingApi和PageableCall(或UnifiedPageableApi)中,易于维护和扩展。
- 增强可读性: 调用方代码通过PagingApi.of(...)清晰地表达了参数绑定意图。
- 函数式风格: 利用Java 8的Lambda表达式和方法引用,使代码更具函数式编程的优雅。
- 性能优化: 推荐将递归分页抽取改为迭代实现,以避免栈溢出并提升效率。
这种模式不仅适用于Feign API,也可以推广到其他需要通用化处理多参数回调或操作的场景,是Java中利用函数式编程解决实际问题的一个典型应用。










