Java 流是迭代器设计模式的实现吗？[已关闭]

Question

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

那么，如题所问，Java流可以被认为是迭代器模式的实现吗？

我们可以认为<代码>。stream()调用创建某种迭代器，允许您解析该集合的元素，而不实际暴露集合的表示？(如果我没弄错的话，这就是迭代器模式的含义)

编辑：为了避免混淆，请注意，我对Java的迭代器接口不感兴趣，我只想知道JavaStreams是否可以被视为迭代器设计模式的实现，为什么？

Answer 1

我们是否可以认为对集合的 .stream（） 调用会创建某种迭代器？

是的，我们可以！但有趣的问题是，它是什么样的迭代器？迭代器设计模式最初发表在GoF的书中。在第260页，它指出，

迭代器有许多实现变体和替代方案。

我们可能不会将流识别为迭代器，因为(在Java中)我们太习惯于看到客户端显式调用< code>next()和< code>hasNext()的模式版本。流显然不是迭代器模式的那个版本，那么它们是什么呢？

谁控制迭代？一个基本问题是决定哪一方控制迭代，迭代器或使用迭代器的客户端。当客户端控制迭代时，迭代器称为外部迭代器，当迭代器控制它时，迭代器是内部迭代器。使用外部迭代器的客户端必须推进遍历，并从迭代器中显式请求下一个元素。相反，客户端向内部迭代器递交要执行的操作，迭代器将该操作应用于聚合中的每个元素。

毫无疑问，Java流API的设计考虑到了迭代器模式，特别是模式的内部版本，因为Stuart Marks和Brian Goetz都在这里优雅地发布了他们的设计决策。Stuart提到了初始原型是如何基于＜code＞Iterable＜code＞本身的。这对于并行处理来说是不够的，Brian描述了流API的最终实现现在是如何基于＜code＞拆分器＜code＞的。

因此Stream仍然是一个迭代器，但它是一个内部迭代器，而不是像Iterator和枚举这样的旧JavaAPI。