17370845950

本文探讨了如何通过java函数式接口和参数绑定技术，通用化处理不同参数数量的feign分页api调用。通过引入泛型接口和静态工厂方法，我们能够将多参数的api调用统一抽象为仅需页码和大小的接口，从而大幅减少重复代码，提升代码的可维护性和可读性，并优化了分页数据抽取逻辑。

1. 问题背景与挑战

在实际项目开发中，我们经常需要调用各种分页API来获取大量数据。当使用Feign客户端调用这些API时，通常会面临以下挑战：

• 参数数量不一： 不同的Feign API可能需要不同数量的业务参数，但它们的共同点是最后两个参数通常是页码（page）和页面大小（size）。
• 数据结构相似但核心数据类型不同： 返回的分页数据结构（如包含总页数、总条数等）通常是相似的，但实际的核心数据列表类型（例如List、Listail>）会因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调用统一抽象为仅接受页码和页面大小的接口。

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 对应 PagingApi1

drainFeignPageableCall(
    new PageableCall(
        // 使用 PagingApi.of 绑定业务参数 "34596"，生成一个 PagingApi 实例
        PagingApi.of(ordersFeignClient::getOrdersBySampleIds, "34596")
    )
);

现在，无论ordersFeignClient中的方法有多少个业务参数，我们都可以通过PagingApi.of方法将其“适配”成一个统一的PagingApi实例，然后传递给PageableCall。这极大地减少了为每个API编写重复抽象的需要。

3. 分页数据抽取逻辑优化

原始的drainFeignPageableCall方法使用了递归实现。虽然递归在某些场景下具有函数式风格，但在处理大量分页数据时，可能会导致栈溢出（StackOverflowError），并且通常不如迭代（循环）效率高。建议将其重构为迭代方式。

3.1 原始递归实现（作为对比）

public  List> 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;

public  List> 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中利用函数式编程解决实际问题的一个典型应用。