java - 在不更改原始方法签名的情况下对服务方法进行分页调用

Question

我有一个用例，我需要将分页输入(即页码和页面大小)添加到现有服务调用(返回结果列表)而不更改现有签名(因为它会破坏现有客户端)。实现这一点的一种方法是我们在线程本地设置输入并让实现读取线程本地并执行其分页逻辑。从代码的角度来看，它看起来像这样:

try {
    PaginationKit.setPaginationInput(pageSize, pageNumber); // Set threadlocal
    List<SpecialObject> results = specialService.getSpecialObjs(); //results count will be equal to pageSize value
} finally {
    PaginationKit.clearPaginationInput(); // Clear threadlocal
}

从客户的角度来看，这一点都不优雅，我想将此功能包装到一些更好的语法糖中。我想到了两种方法，我想知道这是否是一个足够通用的用例，是否已在其他地方作为模式得到解决。有许多这样的服务，尝试为每个服务设置一个装饰器是不可取的。

方法一:我喜欢 Mockito.when(methodCall).thenReturn(result) 的 mockito 风格一种糖。所以代码可能看起来像:

SpecialService specialService = PaginationDecorator.prepare(SpecialService.class); // Get a spy that is capable of forwarding calls to the actual instance
List<SpecialObject> results = PaginationDecorator.withPageSize(pageSize).onPage(pageNumber).get(specialService.getSpecialObjs()).get(); // The get() is added to clear the threadlocal

我试图从 Mockito 借用代码来创建 spy ，但是 OngoingStubbing<T>接口(interface)在随后的调用链/创建代码中交织在一起，并且有一些我应该避免的味道。

方法二:使用 java.util.Function 捕获方法调用并接受两个附加参数 pageNumber 和 pageSize 以使用 threadlocals。代码可能看起来像

List<SpecialObject> results = PaginationDecorator.withPaging(specialService.getSpecialObjs(), pageSize, pageNumber);

PaginationDecorator.java:

public static List<T> withPaging(Function<U, List<T>> call, int pageSize, int pageNumber) {
    try {
        PaginationKit.setPaginationInput(pageSize, pageNumber); // Set threadlocal
        return call.apply(); // Clearly, something is missing here!
    } finally {
        PaginationKit.clearPaginationInput(); // Clear threadlocal
    }
}

我无法在这里清楚地表述如何正确使用调用。

谁能告诉我:

• 这两种方法中哪一种更好
• 如果在其他地方可以使用不同的方法将其作为食谱使用
• 建议实现方法 1 或 2 的方法。就我个人而言，#2 似乎更清晰(如果可行)。

请随时批评该方法，并提前感谢您的阅读!

P.S.:我也喜欢 iterator recipe in this question , 但语法糖的主要问题仍然是需要的。

Answer 1

你的第二个变体不起作用，因为你使用了错误的接口(interface)( Function 需要一个输入参数)并且没有语法来创建函数实例，而只是一个普通的调用表达式。

你有几个选择

1. 使用 Supplier .该接口(interface)描述了一个没有参数和返回值的函数。

   public static <T> T withPaging(Supplier<T> call, int pageSize, int pageNumber) {
       try {
           PaginationKit.setPaginationInput(pageSize, pageNumber); // Set threadlocal
           return call.get();
       } finally {
           PaginationKit.clearPaginationInput(); // Clear threadlocal
       }
   }
   

   而不是坚持要求它返回 List<T> ，我们只允许任何提高其多功能性的返回类型。它包括返回 List 的可能性的东西。

   然后，我们可以使用方法引用之一

   List<SpecialObject> results=PaginationDecorator.withPaging(
                       specialService::getSpecialObjs, pageSize, pageNumber);
   

   或 lambda 表达式:

   List<SpecialObject> results=PaginationDecorator.withPaging(
                       () -> specialService.getSpecialObjs(), pageSize, pageNumber);
   

2. 留在Function , 但允许调用者传递所需的参数

   public static <T,R> R withPaging(
       Function<T,R> call, T argument, int pageSize, int pageNumber) {
   
       try {
           PaginationKit.setPaginationInput(pageSize, pageNumber); // Set threadlocal
           return call.apply(argument);
       } finally {
           PaginationKit.clearPaginationInput(); // Clear threadlocal
       }
   }
   

   现在，调用者必须提供一个函数和一个值。由于预期的方法是实例方法，因此可以将接收方实例视为函数参数

   然后，该函数可能会再次指定为(现在未绑定(bind)的)方法引用

   List<SpecialObject> results=PaginationDecorator.withPaging(
           SpecialService::getSpecialObjs, specialService, pageSize, pageNumber);
   

   或 lambda 表达式:

   List<SpecialObject> results=PaginationDecorator.withPaging(
           ss -> ss.getSpecialObjs(), specialService, pageSize, pageNumber);
   

3. 两者都有一个替代方案，求助于 AutoCloseable并尝试使用资源，而不是 try…finally .将辅助类定义为:

   interface Paging extends AutoCloseable {
       void close();
       static Paging withPaging(int pageSize, int pageNumber) {
           PaginationKit.setPaginationInput(pageSize, pageNumber);
           return ()->PaginationKit.clearPaginationInput();
       }
   }
   

   像这样使用它

   List<SpecialObject> results;
   try(Paging pg=Paging.withPaging(pageSize, pageNumber)) {
       results=specialService.getSpecialObjs();
   }
   

   优点是这不会破坏有关您的预期操作的代码流，即与 lambda 表达式不同，您可以修改 protected 代码内的所有局部变量。如果您忘记放入 withPaging 的结果，最近的 IDE 也会警告您在适当的 try(…) 内陈述。此外，如果抛出异常并且在清理内部发生另一个异常(即 clearPaginationInput() )，则与 finally 不同。 , 次要异常不会掩盖主要异常，而是通过 addSuppressed 记录相反。

   这就是我在这里更喜欢的。