问题：

我应该在我的界面上公开流＜T＞吗？

柳星晖

2023-03-14

如果我正在编写.NET代码，我通常会公开IEnumerable

private List<String> _myList;

public IEnumerable<String> MyList
{
    get { return _myList; }
}

现在，我正在编写Java8代码，我正在讨论是否应该公开＜code＞流

private Collection<String> myCollection;

public Stream<String> getStuff() {
    return myCollection.stream();
}

是<代码>流

共有3个答案

万俟渊

2023-03-14

在接口中尽可能避免流。

流可以*是有限的或无限的*是顺序的或平行的*是有序的或非有序的*需要关闭或不关闭

接口的实现者和接口的客户端都不知道应该（不）应用这些特性中的哪些，或者他们需要防范哪些。

在接口中选择最灵活的返回类型只意味着客户机承担了防范所有可能性的全部责任。在接口中，通常更有用的是限制返回的数据类型，以便实现者知道他们可以依赖什么假设（出于同样的原因，返回＜code＞Collection

当您需要更改返回数据的特征时，更改接口，b故意中断客户机，以便他们可以根据更改的情况更新算法。

这比说：“我的方法返回一个Stream，所以现在我可以返回一个无限的流而不是一个有限的流，并且客户端代码仍然编译，多么美妙！这并不美妙，这样做是一个可怕的错误来源。客户端代码不应该继续以如此剧烈的变化进行编译，因此使用明确关于有限性，并行性，有序性和关闭（）义务的数据类型是一个更好的选择。

这样想：如果保持灵活性非常好，那么Java7中返回＜code＞List

顾承平

2023-03-14

您是否想自己成为Stream，主要取决于您是否真正是一个具有相应功能的Stream，即支持并行化（并非所有Streams都这样做，但这是Streams的众多好处之一，而且很重要）。通常我宁愿成为Collection并让自己被相应的API调用Stream编辑。

方法，返回流

濮阳赞

2023-03-14

你问错了问题。毕竟，支持两者并不难，例如

Collection<Foo> getStuff();
default Stream<Foo> stuff() {
    return getStuff().stream();
}

因此，使用接口的代码不需要显式 stream（） 调用，而接口的实现者也不需要为此烦恼。

由于您始终通过 Collection.stream（） 或显式公开流支持，因此问题是是否要公开集合。虽然为集合后端提供流很便宜，但从流中收集集合可能会很昂贵。

因此，公开这两种方法的接口表明它们同样可用，而对于不使用＜code＞集合＜/code＞后端的实现，其中一种方法可能比另一种方法昂贵得多。

因此，如果您确定所有实现，包括未来的实现，都将始终使用（或必须支持）Collection，那么通过API将其公开为Collection可能会很有用。s支持Stream不支持的某些操作。如果您支持通过公开的Collection修改底层数据，则尤其如此。

否则，仅支持Stream访问可能是更好的选择。这使实现可以自由地拥有Collection以外的其他后端。但是，这也意味着此API不支持Java之前的Java版本

共有3个答案