本文探讨了如何通过java函数式接口和参数绑定技术，通用化处理不同参数数量的feign分页api调用。通过引入泛型接口和静态工厂方法，我们能够将多参数的api调用统一抽象为仅需页码和大小的接口，从而大幅减少重复代码，提升代码的可维护性和可读性，并优化了分页数据抽取逻辑。
1. 问题背景与挑战
在实际项目开发中，我们经常需要调用各种分页API来获取大量数据。当使用Feign客户端调用这些API时，通常会面临以下挑战：
参数数量不一： 不同的Feign API可能需要不同数量的业务参数，但它们的共同点是最后两个参数通常是页码（page）和页面大小（size）。数据结构相似但核心数据类型不同： 返回的分页数据结构（如包含总页数、总条数等）通常是相似的，但实际的核心数据列表类型（例如List、List）会因API而异。重复代码： 如果为每个具有不同业务参数的Feign API都编写一套独立的分页调用和数据抽取逻辑，会导致大量的重复代码，降低开发效率和代码可维护性。
原始的解决方案尝试通过定义特定的接口（如SingleParamPagingApi）和实现类（如SingleParamPageableCall）来处理具有特定参数数量的API。例如：
public interface SingleParamPagingApi { ResponseEntity<IVDPagedResponseOf> 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分页APIpublic interface PagingApi1 { ResponseEntity<IVDPagedResponseOf> callFeignApi(A0 arg0, int page, int size) throws RuntimeException;}// 泛型接口：用于描述具有两个业务参数的Feign分页APIpublic interface PagingApi2 { ResponseEntity<IVDPagedResponseOf> 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<IVDPagedResponseOf> 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 保持不变，用于封装响应和异常@Builderpublic static class BaseFeignResult { private final ResponseEntity<IVDPagedResponseOf> 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 原始递归实现（作为对比）
public List<BaseFeignResult> drainFeignPageableCall(PagedCall feignCall) { BaseFeignResult firstPage = feignCall.call(0, 10); List<BaseFeignResult> 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<BaseFeignResult> drainFeignPageableCall( PagedCall feignCall, BaseFeignResult dataPage, List<BaseFeignResult> 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;public List<BaseFeignResult> drainFeignPageableCallIterative(PagedCall feignCall, int initialPageSize) { List<BaseFeignResult> 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更为通用和健壮。它能正确处理最后一页数据量不足pageSize的情况，也能处理恰好是pageSize倍数的最后一页（尽管这可能导致多一次空请求，但通常是可接受的）。更理想的停止条件是利用API响应中提供的totalElements或totalPages信息。错误处理： 在循环中加入异常检查，确保即使某个分页请求失败，也能优雅地处理或停止。页面大小： 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 可以直接接受 UnifiedPageableApipublic List<BaseFeignResult> 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中利用函数式编程解决实际问题的一个典型应用。
以上就是通用化Java Feign分页API调用：基于函数式接口的参数绑定与数据抽取的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/8586.html
微信扫一扫 
支付宝扫一扫 
