在返回值中替换Collection for Stream是一个好主意吗？

Question

直到Java 8,表示元素集合的属性通常返回Collection.在缺少不可变的集合接口时,常见的习惯用法是将其包装为:

Collection<Foo> getFoos(){ return Collections.unmodifiableCollection(foos); }

现在Stream就在这里,很有可能开始暴露Streams而不是Collections.

我看到的好处是:

1. 一个真正不可变的API
2. 通常情况下,此类属性的客户端对查询或迭代结果感兴趣(如果它想要对集合进行更新,那将是非常糟糕的.).

另一方面,Streams只能使用一次,并且不能像常规集合那样传递.这尤其令人担忧.

这个问题与类似的问题有所不同,因为它更广泛,因为OP明确表示他打算返回的流不会被传递.在我看来,这个方面没有在原始问题的答案中得到解决.

换句话说:在我看来,如果API返回一个流,那么一般的思维方式应该是与它的所有交互必须在直接上下文中终止.应该禁止传递流.

但是,除非开发人员非常熟悉Stream API,否则似乎很难执行.这意味着这种API需要范式转换.我对这个断言是对的吗？

Answer 1

让我提出一个简单的规则：

Stream作为方法参数传递或作为方法的返回值返回的A必须是未终止管道的尾部。

对于我们这些从事流工作的人来说，这可能是显而易见的，以至于我们从来没有费心把它写下来。但对于第一次接触流的人来说，这可能并不明显，因此可能值得讨论。

Streams API 包文档中介绍了主要规则：一个流最多可以有一个终端操作。一旦终止，添加任何中间或终端操作都是非法的。

另一个规则是流管道必须是线性的；他们不能有分支机构。这并没有非常清楚地记录下来，但在Stream 类文档中大约三分之二的地方提到了这一点。这意味着如果中间或终端操作不是管道上的最后一个操作，则将其添加到流中是非法的。

大多数流方法要么是中间操作，要么是终端操作。如果您尝试在已终止或不是最后一个操作的流上使用其中一个，您可以通过获取IllegalArgumentException. 这种情况确实偶尔会发生，但我认为一旦人们意识到管道必须是线性的，他们就会学会避免这个问题，问题就会消失。我认为这对于大多数人来说很容易理解；它不应该需要范式转变。

一旦你理解了这一点，很明显，如果你要将一个Stream实例传递给另一段代码——无论是通过将其作为参数传递，还是将其返回给调用者——它需要是一个流源或最后一个管道中的中间操作。也就是说，它必须是未终止管道的尾部。

换句话说：在我看来，如果 API 返回一个流，一般的思维方式应该是与它的所有交互都必须在直接上下文中终止。应禁止溪流绕过。

我认为这限制太多了。只要您遵守我提出的规则，您就可以随意传递流。事实上，有很多用例可以从某处获取流、修改它并传递它。这里有几个例子。

1) 打开一个文本文件，其中每行包含 POJO 的文本表示形式。致电File.lines()获取Stream<String>. 将每一行映射到一个 POJO 实例，并将 a 返回Stream<POJO>给调用者。调用者可能会应用过滤器或排序操作并将流返回给其调用者。

2) 给定Stream<POJO>，您可能希望有一个 Web 界面来允许用户提供一组复杂的搜索条件。（例如，考虑一个具有大量排序和过滤选项的购物网站。）您可能拥有如下方法，而不是在代码中编写大型复杂的管道：

Stream<POJO> applyCriteria(Stream<POJO>, SearchCriteria)

它将采用一个流，通过附加各种过滤器来应用搜索条件，并可能进行排序或不同操作，并将结果流返回给调用者。

从这些示例中，我希望您可以看到，只要您传递的始终是未终止管道的尾部，传递流就有相当大的灵活性。