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

【问题标题】：Iterator performance contract (and use on non-collections)迭代器性能合同（并用于非集合）
【发布时间】：2010-03-23 15:40:09
【问题描述】：

如果您所做的只是简单的一次性迭代（即只有hasNext() 和next()，没有remove()），您是否可以保证线性时间性能和/或每次操作的摊销恒定成本？

这是在Iterator 合同中的任何地方指定的吗？

是否存在无法在线性时间内迭代的数据结构/Java Collection？

java.util.Scanner implements Iterator<String>。 Scanner 几乎不是数据结构（例如 remove() 完全没有意义）。这算不算设计失误？

像PrimeGenerator implements Iterator<Integer> 这样的东西是否被认为是糟糕的设计，或者这正是Iterator 的用途？（hasNext() 总是返回 true，next() 按需计算下一个数字，remove() 没有意义）。

同样，java.util.Random implements Iterator<Double> 也有意义吗？

如果一个类型实际上只使用了其 API 的三分之一，是否真的应该实现 Iterator？（即没有remove()，总是hasNext()）

【问题讨论】：

不，不，是/否（我认为），不，我觉得很好，不，因为 random 可以返回多种下一个类型 - 你选择哪一个?，最后：如果你有一些东西可以方便地使用该类型的迭代器并且不需要 remove/hasNext，那么对我来说肯定看起来不错

【解决方案1】：

没有这样的保证。正如您所指出的，任何人都可以将任何东西建模为迭代器。迭代器的各个生产者必须指定他们的个人性能。

【讨论】：

【解决方案2】：

Iterator documentaton 中没有提及任何形式的性能保证，因此没有保证。

在这样的通用工具上要求这种约束也是没有意义的。

一个更有用的约束是记录一个iterator() 方法来指定这个Iterator 实例 满足的时间约束（例如一个Iterator 而不是一个通用的Collection将很可能能够保证线性时间操作）。

同样，文档中的任何内容都不需要 hasNext() 返回 false，因此无休止的 Iterator 将完全有效。

但是，一般假设所有Iterator 实例的行为都像Collection.iterator() 返回的“正常”Iterator 实例，因为它们返回一定数量的值，并且在某些情况下结束观点。这不是文档所要求的，严格来说，任何依赖于该事实的代码都会被巧妙地破坏。

【讨论】：

【解决方案3】：

对于Iterator，您的所有建议听起来都很合理。 API 文档明确表示不需要支持 remove，并建议不要使用旧的 Enumeration，它的工作原理与 Iterator 一样，除非没有删除。

此外，无限长度流在函数式编程中是一个非常有用的概念，并且可以使用始终为hasNext 的Iterator 来实现。这是一个可以处理任何一种情况的功能。

【讨论】：

【解决方案4】：

听起来您在考虑列表或集合遍历意义上的迭代器。我认为一个更有用的心智模型是离散对象流，任何你想一次处理一个的东西，可以从源中以离散实例的形式流式传输。

从这个意义上说，质数流或列表对象流都是有意义的，并且模型并不暗示数据源的有限性。

【讨论】：

【解决方案5】：

我可以想象一个用例。它看起来很直观。个人觉得还可以。

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

【讨论】：