具有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方法的“懶惰”特性，因為現在它將做的不僅僅是檢查。