返回流而不是列表

Question

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

所以我曾经拥有过的地方：

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

我现在正在使用：

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

我的论点是：

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

事实上，现在，在我的代码中，返回List或其他一些集合明确表示用户可能会认为该集合是可变的，并且期望能够更改它。

显然，使用不可变集合可以实现其中一些。

我的问题是：任何人都可以看到这种设计的任何缺点吗？返回Stream

是不可变集合的任何优点

Answer 1

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

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

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

Answer 2

我可以想到几个案例：

1. 当来电者真的想要＆＃34;获取并持有＆＃34;值而不是仅处理它们一次。
2. 每次返回新对象时，内存或性能问题都不可接受，最好返回静态对象（这可用于高性能计算，或者您希望在方法中具有确定性处理时间，因此您希望有minumal GC）。

但是很多处理都可以简化。