带有 Java 分页的迭代器设计模式

Question

我正在尝试对 API 进行服务调用，该 API 以分页格式返回结果，并希望为此提供有关迭代器设计模式的建议。

到目前为止我所拥有的是这样的

public class CustomIterator implements Iterator<Type> {

 private List<Result> results;
 private Service service;

 private int index;
 private int paginatedResultSize;
 private int totalResultsSize;

 public CustomIterator(Service service) {
  this.service = service;
  this.index = 0;
  this.results = getResults(index);
  this.totalResultsSize = this.results.totalResultsSize();
 }

 @Override
 public boolean hasNext() {
   if (index < totalResultsSize)
    return true;
   return false;
 }

 @Override
 public Type next() {

  if(index == paginatedResultSize) {
   getResults(index);
  }

  return results[index++];

 }

 private List<Result> getResults(index) throws Exception {
  this.results = service.makeServiceCall(index);
  this.paginatedResultSize = this.results.size();
  return this.results;
 }

}

现在，我明白迭代器的目的通常只是迭代，但我也想将整个分页封装到一个单独的区域，这样我的客户端类就可以在类上调用 .next() 并获取所有值而不必了解内部分页详细信息。是否有一个干净的模式来完成这项工作？

有了这个，我遇到的第一个问题是服务调用抛出了一个已检查的异常，而 next() 显然没有。

我在互联网上注意到的一些选项是让这个抛出 RunTimeException ，我宁愿只作为最后的手段这样做，因为我喜欢服务调用的检查异常。我的直觉是服务调用应该完全在单独的层中完成，但我不确定迭代器将如何处理该分页。任何建议/链接表示赞赏。

Answer 1

这是一种完全可以接受的方法。

您如何处理异常取决于您。如果异常是这样的，AttemptToReadBeyondLimit那么就false从hasNext. 如果它是这样的，CommunicationsException那么一定要抛出一个RuntimeException.

你不应该不必要地添加额外的层。