是“无限”的。迭代器设计不好？

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

想要改进这个问题？更新问题，以便可以通过编辑这篇文章用事实和引文来回答它。

5 年前已关闭。

Answer 1

我认为它是完全合法 - 迭代器只是一个“东西”流。为什么流必须是有界的？

许多其他语言（例如 Scala）都内置了无界流的概念，并且可以对其进行迭代。例如，使用 scalaz

scala> val fibs = (0, 1).iterate[Stream](t2 => t2._2 -> (t2._1 + t2._2)).map(_._1).iterator
fibs: Iterator[Int] = non-empty iterator

scala> fibs.take(10).mkString(", ") //first 10 fibonnacci numbers
res0: String = 0, 1, 1, 2, 3, 5, 8, 13, 21, 34

编辑： 就最小惊喜原则而言，我认为这完全取决于上下文。例如，我希望这个方法返回什么？

public Iterator<Integer> fibonacciSequence();

Answer 2

Iterator 的全部要点是它是惰性的，即它只提供您所要求的对象数量。如果用户请求无限Iterator的所有对象，这是他们的问题，而不是你的问题。

Answer 3

虽然我也认为它是合法的，但我想补充一点，这样一个 Iterator （或更准确地说：一个 Iterable 生成这样一个 Iterator ) 无法与增强型 for 循环（又名 for-each-loop）配合使用：

for (Object o : myIterable) {
   ...
}

由于增强型 for 循环内的代码无法直接访问迭代器，因此无法调用 remove() 在迭代器上。

因此，要结束循环，必须执行以下操作之一：

• 访问 Iterator 的内部 List 并直接删除对象，这可能会引发 ConcurrentModificationException
• 使用 break 退出循环
• “使用”Exception 退出循环
• 使用 return 退出循环

除最后一个之外的所有内容这些替代方案并不完全是留下增强型 for 循环的最佳方式。

当然，“普通”for 循环（或任何其他带有显式迭代器变量的循环）都可以正常工作：

for (Iterator it = getIterator(); it.hasNext();) {
  Object o = it.next()
  ...
}

Answer 4

这可能是语义上的，但迭代器应该努力返回下一个项目，而不考虑它何时结束。结束是集合的副作用，尽管它可能看起来是常见的副作用。

不过，无限与包含 10 万亿项的集合有什么区别？打电话的人要么想要全部，要么不想要。让调用者决定返回多少项或何时结束。

我不会说调用者不能使用 for-each 构造。他可以，只要他想要所有的物品。

集合文档中的某些内容（例如“可能是无限集合”）是合适的，但不是“无限迭代器”。

Answer 5

这是完全合法的使用 - 只要有适当的记录。

使用 CyclicIterator 名称是一个好主意，因为它推断如果没有正确定义循环退出情况，迭代器上的循环很可能是无限的。

Answer 6

当您创建无限数据时，无限迭代器非常有用，例如线性循环序列，如 斐波那契序列 。

所以使用这样的完全没问题。

Answer 7

是的。您只需要一个不同的标准来确定何时停止迭代。

无限列表的概念在 Haskell 等惰性求值语言中非常常见，并导致完全不同的程序设计。

Answer 8

实际上，无论 JavaDoc API 怎么说，Iterator 来自 Iterable，而不是 Collection。后者扩展了前者，这就是为什么它也可以生成 Iterator ，但 Iterable 不成为 Collection 是完全合理的。事实上，甚至有一些 Java 类实现了 Iterable，但没有实现 Collection。

现在，至于期望......当然，如果没有明确表明情况确实如此，则不得提供无限迭代器。但有时，期望可能具有欺骗性。例如，人们可能期望 InputStream 总是结束，但这实际上并不是它的要求。同样，返回从此类流读取的行的迭代器可能永远不会结束。

Answer 9

考虑一下您是否有生成器函数。正如您所注意到的，迭代器可能是生成器的合理接口，也可能不是。

另一方面，Python 的生成器会终止。

Answer 10

我可以想象无限迭代器的任意数量的用途。例如，程序迭代由另一台服务器或后台进程发送的状态消息会怎么样。虽然在现实生活中，服务器可能最终会停止，但从程序的角度来看，它可能会继续读取，直到被与迭代器到达末尾无关的东西停止为止。

这肯定是不寻常的，正如其他人所说，应该仔细记录。但我不会宣布这是不可接受的。

Answer 11

如果您有一个需要迭代器的对象，并且您碰巧给了它一个无限迭代器，那么一切都应该很好。当然，该对象永远不应该要求迭代器停止。 这是潜在的糟糕设计。

想想音乐播放器。您告诉它以“连续播放模式”开始播放曲目，它会播放曲目，直到您告诉它停止为止。也许您可以通过永远随机播放播放列表来实现这种连续播放模式......直到用户按下“停止”。在这种情况下，MusicPlayer 需要迭代播放列表，可能是Collection，永远。在这种情况下，您需要一个您构建的 CyclicIterator 或一个随机选择下一个轨道且永不耗尽的 ShuffleIterator。到目前为止，一切都很好。

MusicPlayer.play(Iteratorplaylist) 不会关心播放列表是否结束。它既可以与轨道列表上的迭代器一起使用（播放到最后，然后停止），也可以与轨道列表上的 ShuffleIterator

一起使用（永远选择随机轨道）。一切都还好。

如果有人尝试编写 MusicPlayer.playContinuously() ，希望“永远”播放曲目（直到有人按下“停止”），但接受 Iterator 该怎么办？ > 作为参数？ 这就是设计问题。显然，playContinuously() 需要一个无限的 Iterator，如果它接受一个普通的 Iterator 作为其参数，那么那就不好了设计。例如，它需要检查 hasNext() 并处理返回 false 的情况，即使它永远不应该发生。坏的。

因此，实现您想要的所有无限迭代器，只要它们的客户端不依赖这些迭代器的结尾即可。就好像您的客户端依赖于永远运行的迭代器一样，那么不要给它一个简单的迭代器。

这应该是显而易见的，但似乎并非如此。