迭代器性能合同（并用于非集合）

如果您所做的只是简单的一次迭代（即只有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

回答