迭代器性能合同（並用於非集合）

如果您所做的只是簡單的一次迭代（即只有hasNext()和next()，而不是remove()），您是否保證線性時間性能和/或攤銷常數每次操作的成本？迭代器性能合同（並用於非集合）

請問這Iterator合同中規定的地方？不能在線性時間內反覆

是否有數據結構/ Java的Collection？

java.util.Scanner implements Iterator<String>。 A Scanner幾乎不是數據結構（例如remove()絕對沒有意義）。這是否被認爲是設計失誤？

就像PrimeGenerator implements Iterator<Integer>被認爲是壞的設計，或者這正是Iterator是什麼？（hasNext()總是返回true，next()按需計算下一個數字，remove()沒有意義）。

同樣，將它取得了有意義的java.util.Random implements Iterator<Double>？

如果一個類型，如果它只是有效使用其API的三分之一真正落實Iterator？（即，沒有remove()，總是hasNext()）

否，不，是/否（我*認爲*），不，我看起來很好，沒有，因爲隨機可以返回各種各樣的下一類型 - 你選擇哪一種？最後：如果你有什麼會方便地使用這種類型的迭代器，並且不需要remove/hasNext，對我來說確實很好看 – Carl 2010-03-23 20:35:06

沒有這樣的保證。正如你指出的那樣，任何人都可以將任何東西建模爲迭代器。迭代器的個體生產者將不得不指定他們的個人表現。

2010-03-23 15:42:29 bmargulies

less words = better ;-) – 2010-03-23 15:48:03

Iterator documentaton中沒有提及任何類型的性能保證，因此不能保證。

在這樣一個通用工具上要求這個約束也是沒有意義的。

甲有用得多約束是文檔iterator()方法來指定時間約束此Iterator實例滿足（例如一個Iterator過通用Collection將最有可能能夠保證線性時間操作）。

同樣，文檔中沒有任何內容需要hasNext()永遠返回false，所以無盡的Iterator將是完全有效的。

但是，所有Iterator情況下表現得像「普通」 Iterator實例作爲在返回的Collection.iterator()它們返回值的一些號碼，並在某些時候年底一般的假設。這不是文檔所要求的，嚴格來說，取決於這個事實的任何代碼都會被細微地破壞。

2010-03-23 15:47:43

對於Iterator，您的所有提議聽起來都合理。 API文檔明確指出remove不需要支持，並且建議不使用舊的Enumeration，其工作方式與Iterator一樣，除非不刪除。

此外，無限長度的流在函數式編程中是一個非常有用的概念，可以使用Iterator來實現，它總是hasNext。這是一個可以處理這兩種情況的功能。

2010-03-23 17:20:37

我可以想象一個這樣的用例。它看起來很直觀。我個人認爲這很好。

for(long prime : new PrimeGenerator()){ 
    //do stuff 
    if(condition){ 
     break; 
    } 
}

2010-03-23 17:39:38

更不用說，if（condition）*可以*在hasNext中表示 - 無論如何更方便的編碼，因爲你有。 – Carl 2010-03-23 20:30:52

這聽起來像你正在考慮列表或遍歷意義上的迭代器。我認爲一個更有用的心智模型是一個離散的對象流，你可以一次處理一個可以從一個源以流派離散的實例流的東西。

從這個意義上來說，素數或列表對象流都是有意義的，並且該模型並不暗示關於數據源的有限性的任何事情。

2010-03-23 19:59:26

回答