返回流而不是列表 [重复]

Question

在Java 8中，我越来越多地用Stream替换集合返回值。

所以我曾经有:

public List<Element> getElementList() {
    return elements;
}

我现在使用：

public Stream<Element> streamElements() {
    return elements.stream();
}

我对此的论点是:

1. 它强制执行基础列表的不变性。
2. 它隐藏了存在基础列表的事实。之后可以将其更改为集合或其他结构，而无需更改方法签名
3. 它很好地封装了该方法的用户希望对项进行处理，而不是对列表进行处理
4. 如果需要，它可以在以后进行简单的并行化

事实上，现在，在我的代码中，返回＜code＞列表

显然，其中一些可以通过不可变集合来实现。

我的问题是:有人能看出这个设计的缺点吗？与返回< code>Stream相比，不可变集合有什么优势吗？

Answer 1

我可以想出几个例子：

1. 当调用者真的想要“获取并保存”这些值而不是只处理它们一次时。
2. 当每次返回一个新对象时，内存或性能问题是不可接受的，其中返回静态对象更可取（这对于高性能计算是可能的，或者您希望方法中具有确定性流转时长，因此您希望有微小的GC）。

但是，是的，可以简化很多处理。

Answer 2

我并不是说你不应该返回一个Stream，更不是说你不应该返回一个Stream，但这样做也有很多缺点：

• 它不会告诉API的用户集合是有序的（List）还是不有序的（Set），或者是排序的（SortedSet）
• 它不会告诉API的用户集合是否可以包含重复项（List）或不包含重复项（Set）
• 它不允许用户轻松快速地访问列表的第一个或最后一个元素，甚至不知道它的大小。
• 如果API的用户需要对集合进行多次传递，他将被迫将每个元素复制到新集合中。

我想说，选择返回流而不是集合也取决于您已经拥有的内容。如果集合已经物化（想想一个JPA实体已经将OneTo很多物化为Set），我可能会在集合上返回一个不可变的包装器。另一方面，如果要返回的集合是另一个集合的计算或转换的结果，则返回Stream可能是更好的选择。