java.util.Collection 为什么不实现新的 Stream 接口？

Question

我刚刚花了一些时间开始研究有关流和 lambda 的 java-8 嗡嗡声。令我惊讶的是，您不能直接在java.util.Collection 上应用流操作，例如.map()、.filter()。 java.util.Collection 接口未扩展是否有技术原因 这些 Stream 操作的默认实现？

谷歌一下，我看到很多人按照以下模式编码的例子：

List<String> list = someListExpression;
List<String> anotherList = list.stream().map(x -> f(x)).collect(Collectors.toList());

如果您的代码中有很多这样的流操作，这将变得非常笨拙。由于.stream()和.collect()与你想表达的内容完全无关，你宁愿说：

List<String> list = someListExpression;
List<String> anotherList = list.map(x -> f(x));

Answer 1

是的，这些决定有很好的理由:)

关键是eager和lazy操作的区别。您在第一个问题下给出的示例显示了映射或过滤列表产生新列表的急切操作。这并没有错，但这通常不是你想要的，因为你经常做的工作比你需要的多；急切的操作必须对每个元素进行操作，并产生一个新的集合。如果您正在组合多个操作（filter-map-reduce），那么您正在做很多额外的工作。另一方面，惰性操作组合起来很漂亮。如果你这样做：

Optional<Person> tallestGuy = people.stream()
                                    .filter(p -> p.getGender() == MALE)
                                    .max(comparing(Person::getHeight));

filter 和 reduce (max) 操作融合在一起成为一个单通道。这是非常有效的。

那么，为什么不在 List 上公开 Stream 方法呢？好吧，我们就这样试过了。在众多其他原因中，我们发现混合使用像 filter() 这样的惰性方法和像 removeAll() 这样的急切方法会让用户感到困惑。通过将惰性方法分组到一个单独的抽象中，它变得更加清晰； List 上的方法是改变列表的方法； Stream 上的方法是那些处理对数据序列的可组合、惰性操作的方法，无论数据位于何处。

因此，如果您想做非常简单的事情，那么您建议的方式非常好，但是当您尝试在此基础上进行构建时开始崩溃。额外的stream() 方法烦人吗？当然。但是保持数据结构（主要是关于在内存中组织数据）和流（主要是关于组合聚合行为）的抽象分离可以更好地扩展到更复杂的操作。

对于第二个问题，您可以相对轻松地做到这一点：像这样实现流方法：

public<U> Stream<U> map(Function<T,U> mapper) { return convertToStream().map(mapper); }

但这只是逆潮流而动；最好只实现一个高效的 stream() 方法。