在Java8中，返回元素流的良好实践

假设我有一个库中c类的对象c，所以我不能修改扩展Iterable的类定义

在我的函数中，我想为用户提供一种处理类型R的对象流的方法，其中类型R的对象是通过对类型T的对象进行转换而获得的

目前我做了以下工作：

Stream<R> f(...) {
  C c = ...;
  return StreamSupport.stream(c.spliterator(), false)
  .map(...);
}

它之所以能工作，是因为拆分器是在类Iterable中默认实现的，但javadoc表示，出于性能原因，不建议使用默认实现

如果用户只想处理或应用流操作，我想返回一个流，而不是创建一个列表。 我对流的并行化属性不感兴趣，因为c中的对象只能按顺序读取

所以我想知道，如果有建议的话，做这类事情的方法是什么。简单地返回一个列表还是传递一个消费者函数作为参数更好？我有点担心javadoc建议不要使用默认拆分器implem。

---

使用上面描述的方法，我可以保证在底层流中保持元素的外观顺序吗？

规范没有说您不应该使用它：“通常应覆盖默认实现。”很明显，如果你不是C类的维护者，你就不能对C类做任何事情。但是重要的一点是，你使用C.spliterator的方式并不妨碍C类的维护者提供一个定制的spliterator实现，所以这没有什么错

毕竟，使用默认拆分器实现的缺点（如没有拆分功能）也适用于所有其他解决方案。您不能添加这样的功能，只有C的维护人员可以这样做。以这种方式构造的流的性能不会比使用普通迭代器更差，因为这正是默认实现在后台使用的。但是使用流可以获得C.spliterator未来实现的优势

---

如果您知道C的特性或大小，您可以，但这确实会干扰C类的未来发展，因此请谨慎使用。

规范并没有说您不应该使用它：“通常应覆盖默认实现。”很明显，如果你不是C类的维护者，你就不能对C类做任何事情。但是重要的一点是，你使用C.spliterator的方式并不妨碍C类的维护者提供一个定制的spliterator实现，所以这没有什么错

毕竟，使用默认拆分器实现的缺点（如没有拆分功能）也适用于所有其他解决方案。您不能添加这样的功能，只有C的维护人员可以这样做。以这种方式构造的流的性能不会比使用普通迭代器更差，因为这正是默认实现在后台使用的。但是使用流可以获得C.spliterator未来实现的优势

如果你知道C的特征或大小，你可以，但这确实会干扰C类的未来发展，因此要小心使用