为什么没有提供流的接口？

Question

为了防止实现细节泄漏，可以实现iterable ，而不是返回集合 ，然后需要从iterable接口实现迭代器 。因此，无论内部数据结构如何管理，对元素的访问都是通过迭代器进行的。

对于Java8，可能希望将stream stream() 添加到myCoolObject。（另请参阅《Java8lambdas》一书中关于支持stream的建议）。虽然添加方法并不困难（我也读过关于为什么Iterable不提供流的问题），但奇怪的是Java没有为Streamable 添加接口来镜像Iterable 思想。（好吧，可能有一个不同的名称，因为streamable是为了永远使用CORBA的东西而存在的）。

我想我已经回答了为什么将stream添加到iterable可能会有问题，但我不明白为什么不能提供streaming 接口。例如，collections可以实现streaming 接口，对于其他对象来说，这会使我们更清楚地看到一个stream()方法。

根据对上述问题的回答，可以通过以下方式从iterable获取流

Stream s = StreamSupport.stream(iter.spliterator(), false);

但鉴于MyObject可能希望只实现stream()以允许对象的用户执行以下操作，这似乎需要大量的工作

myObject.stream().filter(...).collect(...)

而不需要从迭代器进行中间转换。

缺少流式处理对象的接口是有原因的吗？除了在MyCoolObject上实现stream()并让用户查看Javadoc以便知道它有stream()方法之外，还有更好的方法吗？

Answer 1

这可能会增加将来的答案。

我不知道为什么您认为返回一个可迭代的 而不是一个集合 更好。它可能确实隐藏了细节，而且还会制造更多的问题。

集合的已知大小在进行并行处理的拆分时起着很大的作用。这被报告为spliterator.sized spliterator.sublided。因此，collection.stream将比iterable更好地处理并行流，它将使用：

public static <T> Spliterator<T> spliteratorUnknownSize 

记录为：

...并实现trySplit以允许有限的并行性。

这很明显，因为你根本不知道大小。在当前实现下，批处理大小为1024。因此，例如，对于1024个元素以下的任何东西，您将不会得到任何并行化。

String::codePoints()
File::lines
Pattern::splitAsStream
... many others

以下是删除的原因：

我正在考虑放弃流式接口。目前唯一的实现者是Collection，所有其他包含流的方法都提供专用流(chars()、codePoints()、lines()等），其方法名比“stream”更合适。所以我认为我们应该删除Streamable并将stream（）/parallel（）方法保留在Collection上（或者可能将它们向上移动为Iterable）。