lambda - 在返回值中用 Collection 代替 Stream 是个好主意吗？

Question

直到 Java 8，表示元素集合的属性通常返回一个 Collection。在没有不可变集合接口(interface)的情况下，常见的习惯用法是将其包装为:

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

现在 Stream 就在这里，很容易开始公开 Streams 而不是 Collections。

我认为的好处:

1. 真正不可变的 API
2. 大多数情况下，此类属性的客户端有兴趣查询或迭代结果(如果想要更新集合，那将非常糟糕......)。

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

这个问题与 similar looking question 不同因为它的意义更广泛，那里的OP明确表示他打算返回的流不会被传递。在我看来，原始问题的答案中并未涉及这一方面。

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

但是，这似乎很难执行，除非开发人员非常熟悉 Stream API。这意味着这种 API 需要范式转变。我的这个说法正确吗？

Answer 1

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

A Stream that is passed as a method argument or returned as a method's return value must be the tail of an unterminated pipeline.

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

主要规则包含在 Streams API package documentation 中:一个流最多可以有一个终端操作。一旦终止，添加任何中间或终端操作都是非法的。

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

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

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

To put in other words: it seems to me that if an API returns a stream, the general mindset should be that all interaction with it must terminate in the immediate context. It should be forbidden to pass the stream around.

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

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

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

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

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

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