Java Streams 是迭代器设计模式的实现吗？ [关闭]答案

【问题标题】：Are Java Streams implementations of Iterator Design Pattern? [closed]Java Streams 是迭代器设计模式的实现吗？ [关闭]
【发布时间】：2020-09-09 10:20:57
【问题描述】：

那么，正如标题所问的，Java Streams 可以被视为迭代器模式的实现吗？

我们是否可以认为 Collection 上的 .stream() 调用创建了某种迭代器，允许您解析该 Collection 的元素，而不实际暴露 Collection 的表示？（如果我没记错的话，这就是迭代器模式所暗示的）

编辑： 为避免混淆，请注意我对 Java 的 Iterator 接口不感兴趣，我只想知道 Java Streams 是否可以被视为 Iterator Design Pattern 的实现，为什么？

【问题讨论】：

这能回答你的问题吗？ Iterator versus Stream of Java 8
@HadiJ 这是 Java 的 Iterator 和 Stream 之间的一个有用的比较，它们都有优点和缺点，但我实际上更感兴趣的是，如果我们真的可以将 Java 的 Stream 视为有效的实现迭代器设计模式，为什么？ :D
流的设计是为了回答“我们如何为任何聚合对象类型实现通用迭代”这个问题？不。作为它们的功能之一，它们是否允许程序员以这种方式使用它们？是的。这个问题是否可能产生基于意见的答案，因此应该关闭？也可以。

标签： java design-patterns iterator java-stream

【解决方案1】：

我们可以认为 Collection 上的 .stream() 调用创建了某种迭代器吗？

是的，我们可以！但有趣的问题是，它是什么样的迭代器？

迭代器有许多实现变体和替代方案。（第 260 页）

我们可能无法将流识别为迭代器，因为（在 Java 中）我们非常习惯于查看客户端显式调用 next() 和 hasNext() 的模式版本。流显然不是迭代器模式的那个版本，那么它们是什么？

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

所以Stream 仍然是一个迭代器，但它是一个内部迭代器，而不是像Iterator 和Enumeration 这样的旧Java API。

【讨论】：

引述来自 GoF 书籍。