当前位置: 首页 > 知识库问答 >
问题:

我应该返回集合还是流?

山森
2023-03-14

假设我有一个方法将只读视图返回到成员列表中:

class Team {
    private List<Player> players = new ArrayList<>();

    // ...

    public List<Player> getPlayers() {
        return Collections.unmodifiableList(players);
    }
}

进一步假设客户机所做的只是立即对列表进行一次迭代。也许是为了把玩家放进一个JList或者别的什么。客户端没有存储对列表的引用以供以后检查!

对于这种常见的场景,我是否应该返回一个流呢?

public Stream<Player> getPlayers() {
    return players.stream();
}

还是返回流在Java中不是惯用的?流被设计成总是在创建它们的同一个表达式中“终止”吗?

共有1个答案

益兴生
2023-03-14

答案是一如既往的“视情况而定”。这取决于返回的收藏会有多大。这取决于结果是否随时间变化,以及返回结果的一致性有多重要。这在很大程度上取决于用户可能如何使用答案。

首先,请注意,您始终可以从流中获取集合,反之亦然:

// If API returns Collection, convert with stream()
getFoo().stream()...

// If API returns Stream, use collect()
Collection<T> c = getFooStream().collect(toList());

所以问题是,哪一个对你的呼叫者更有用。

即使您知道用户将多次迭代它或保留它,您仍然可能希望返回一个流,因为一个简单的事实,即您选择将它放入的任何集合(例如,ArrayList)可能不是他们想要的表单,然后调用者必须复制它。如果返回一个流,他们可以执行collection(toCollection(factory))并以他们想要的形式获得它。

以上“偏爱流”的案例,大多源于流更灵活;您可以对如何使用它进行后期绑定,而不会产生将它物化到集合中的成本和限制。

必须返回集合的一种情况是有很强的一致性要求,并且必须生成移动目标的一致快照。然后,您需要将元素放入一个不会更改的集合中。

所以我要说,大多数时候,Stream是正确的答案--它更灵活,不会增加通常不必要的物化成本,并且如果需要,可以很容易地转换为您选择的集合。但有时,您可能必须返回集合(例如,由于强烈的一致性要求),或者您可能希望返回集合,因为您知道用户将如何使用它,并且知道这对他们来说是最方便的事情。

如果您已经有一个合适的集合“到处都是”,并且您的用户似乎更愿意将其作为集合进行交互,那么仅仅返回您所拥有的内容是一个合理的选择(尽管不是唯一的选择,而且更脆弱)。

 类似资料:
  • 问题内容: 假设我有一个将只读视图返回到成员列表的方法: 进一步假设所有客户要做的就是立即遍历列表一次。也许将播放器放入JList之类。客户端就不能存储到列表的引用以便稍后进行检查! 在这种常见情况下,我应该返回流吗? 还是在Java中返回流非惯用语?流是否设计为始终在创建它们的相同表达式内被“终止”? 问题答案: 答案是一如既往的“取决于”。这取决于返回的集合的大小。这取决于结果是否随时间变化,

  • 问题内容: 我发现自己同意返回接口而不是具体的类。 原因很简单,我要松散耦合。 但是还会有其他影响或权衡吗? 问题答案: 对于List或ArrayList之类的类型,不应进行任何编译,并且应将List提升Code返回到接口。 如果这是通过诸如CopyOnWriteArrayList之类的并发包进行的,并且您使用的是addIfAbsent之类的方法(未在List接口中定义),您将发现自己受到限制。

  • 我发现自己同意返回一个接口,而不是一个具体的类。

  • 在构建API时,编写接口代码是一个很好的实践,因此返回CompletionStage似乎是一个最好的方法。然而,我意识到我碰巧总是在获得CompletionStage之后调用.ToCompletableFuture。在这种情况下,推荐的方法是什么?

  • 问题内容: 我正在使用c / c 为osx和linux开发命令行界面可执行文件。该项目将链接到opencv。我应该使用libc 还是libstdc ++? 问题答案: 我会为每个操作系统使用本机库,即GNU / Linux上的libstdc 和Mac OS X上的libc 。 libc 在GNU / Linux上不是100%完整的,而libstdc 更完整时使用libc并没有真正的优势。另外,如果

  • 问题内容: 和CSS 和有什么不一样?我应该使用哪一个?为什么? 问题答案: 所有这些答案似乎都是不正确的。与直觉相反,在CSS 中不是pixel 。至少不是在简单的物理意义上。 从W3C,EM,PX,PT,CM,IN…阅读本文,了解如何为CSS发明一个“神奇的”单元。的含义因硬件和分辨率而异。(该文章是最新的,最新更新为2014-10。) 我自己的思考方式: px单位是CSS的魔术单位。它与当前