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，则仅从hasNext返回false。如果它是类似于CommunicationsException的东西，那么无论如何抛出一个RuntimeException。

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

Answer 2

如前所述，Iterator设计模式API的常见用法要求next方法是安全的。因此，您很少会不看到这种代码：

for(... iter. hasNext() ...) {
Type t = iter.next();
...
}

所以，我认为在设计Iterator-Service代理时应该记住这一点。我目前看到的一个误用是你提到的——关于next()抛出异常。

我会尝试通过做两件事之一来找到一种检查异常的方法：

1. 在服务API中创建一个"标志">-这意味着您现在将有两个可用的服务，一个称为"isMoreDataAvailable"，另一个名为"getData"。

   2. 制作一个内部容器-这意味着hasNext方法实际上将从服务中提取数据，并将其存储在内部数据结构中，以便next方法在调用时获取

第一个方法的缺点是重新设计服务API的问题，而不是总是可能的或向后兼容的。第二个方法的缺点是事实上打破了hasNext方法的"懒惰"特性，因为现在它将做的不仅仅是检查。