在诸如Stream.reduce（）之类的API中选择不变性的充分理由是什么？

仔细浏览lambda开发的历史并找出做出该决定的“ THE”原因很困难-因此，最终，人们将不得不等待其中一名开发者回答此问题。

一些提示可能如下：

• 流接口经历了多次迭代和重构。在最早的

  Stream

  接口版本之一中，有专用的

  reduce

  方法，而

  reduce

  在问题中最接近该方法的方法仍被调用

  Stream#fold

  。这个已经收到一个

  BinaryOperator

  作为

  combiner

  参数。

• 有趣的是，很长一段时间以来，lambda建议包括一个专用接口

  Combiner<T,U,R>

  。违反直觉的是，此功能未在

  combiner

  中使用

  Stream#reduce

  。取而代之的是，它被用作

  reducer

  ，这似乎是当今称为的

  accumulator

  。但是，该

  Combiner

  接口在以后的版本中被替换

  BiFunction

  。

• 与问题最相似的地方是在邮件列表中有关

  Stream#flatMap

  签名的线程中，然后将其转变为有关流方法签名差异的一般问题。他们将它们固定在某些地方，例如

正如Brian纠正我的那样：

<R> Stream<R> flatMap(Function<? super T, ? extends Stream<? extends R>>mapper);

代替：

<R> Stream<R> flatMap(Function<T, Stream<? extends R>> mapper);

但是请注意，在某些地方这是不可能的：

T reduce(T identity, BinaryOperator<T> accumulator);

和

Optional<T> reduce(BinaryOperator<T> accumulator);

由于使用了“ BinaryOperator”，因此无法修复，但是如果使用“ BiFunction”，则我们具有更大的灵活性

<U> U reduce(U identity, BiFunction<? super U, ? super T, ? extends U>accumulator, BinaryOperator<U> combiner)

代替：

<U> U reduce(U identity, BiFunction<U, ? super T, U> accumulator,BinaryOperator<U> combiner);

关于“ BinaryOperator”的相同评论

（我强调）。

我发现 不 替换为

BinaryOperator

BiFunction

正如您所说，即使BinaryOperator引入了更大的灵活性，它也不会被BiFunction取代，BinaryOperator要求两个参数和返回类型相同，因此从概念上讲它的权重更大（EG已经对此进行了投票）。

也许有人可以从中得出决定这一决定的专家组投票的具体参考，但也许这句话已经充分回答了为什么是这样的问题。