【问题标题】:Returning stream rather than list [duplicate]返回流而不是列表[重复]
【发布时间】:2015-03-25 17:39:13
【问题描述】:

在 Java 8 中,我越来越多地将 Collection 返回值替换为 Stream

所以我曾经拥有的地方:

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

我现在正在使用:

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

我的论点是:

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

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

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

我的问题是:任何人都可以看到这种设计的任何缺点吗?与返回 Stream 相比,不可变集合有什么优势吗?

【问题讨论】:

标签: java java-8 java-stream


【解决方案1】:

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

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

我会说选择返回流而不是集合还取决于您已经拥有什么。如果集合已经物化(考虑一个 JPA 实体,其 OneToMany 已经物化为 Set),我可能会在集合上返回一个不可变的包装器。另一方面,如果要返回的集合是另一个集合的计算或转换的结果,则返回 Stream 可能是更好的选择。

【讨论】:

  • 这是一个很好的答案,我已经接受了,但是在阅读了另一个答案之后,很明显这确实是一个重复的问题。话虽如此,我更喜欢你的答案而不是另一个,所以你可能想在那里重新发布。
  • +1:Brian Goetz 的回答强烈支持Stream,但实际上,使用 Stream 的唯一真正令人信服的理由是懒惰。基本上,Stream 是对 Iterator 的改进,远远超过对 Collection 的改进。
【解决方案2】:

我能想到几种情况:

  1. 当调用者真正想要“获取并保留”这些值而不是只处理一次时。
  2. 由于内存或性能问题,每次返回新对象都不可接受时,最好返回静态对象(这对于高性能计算或您希望在方法中具有确定性处理时间的情况是可能的,因此您希望GC 最少)。

但是可以简化很多处理。

【讨论】:

    猜你喜欢
    • 2021-09-18
    • 2021-10-07
    • 1970-01-01
    • 2019-03-17
    • 2022-11-09
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-09-02
    相关资源
    最近更新 更多