Java 8 方法签名中的不一致

Question

Java 8 为我们提供了具有非常长签名的新方法，如下所示：

static <T,K,U,M extends Map<K,U>> Collector<T,?,M> toMap(
    Function<? super T,? extends K> keyMapper, 
    Function<? super T,? extends U> valueMapper, 
    BinaryOperator<U> mergeFunction, Supplier<M> mapSupplier)

我觉得奇怪的是通配符被用来确保前两个参数尽可能通用，而第三个参数只是一个BinaryOperator<U>。如果他们一直保持一致，那肯定是BiFunction<? super U,? super U,? extends U>?。我错过了什么吗？这样做有充分的理由吗，还是他们只是想避免让已经很可怕的签名变得更糟？

编辑

我了解 PECS，并且我了解 mergeFunction 应该被认为是获取两个 Us 并取回 U 的一种方式。然而，能够拥有一个可以以多种不同方式重用的对象将会很有用。例如：

static final BiFunction<Number, Number, Double> 
        MULTIPLY_DOUBLES = (a, b) -> a.doubleValue() * b.doubleValue();

显然这不是BinaryOperator<Double>，但可以将其视为。如果您可以将MULTIPLY_DOUBLES 用作both BiFunction<Number, Number, Double> 和BinaryOperator<Double>，那就太好了，具体取决于上下文。特别是，您可以简单地传递 MULTIPLY_DOUBLES 以表明您希望使用乘法来减少 doubles 的负载。然而，toMap（以及 Java 8 中的其他新方法）的签名不允许这种灵活性。

Answer 1

你是对的，merge 操作的功能签名（同样适用于 reduce）不需要像 BinaryOperator 这样的接口。

这不仅可以通过toMap 收集器的mergeFunction 以Map.merge 结束这一事实来说明，Map.merge 接受BiFunction<? super V,? super V,? extends V>；您也可以将这样的BiFunction 转换为所需的BinaryOperator：

BiFunction<Number, Number, Double> 
    MULTIPLY_DOUBLES = (a, b) -> a.doubleValue() * b.doubleValue();
Stream<Double> s = Stream.of(42.0, 0.815);
Optional<Double> n=s.reduce(MULTIPLY_DOUBLES::apply);

或完全通用：

public static <T> Optional<T> reduce(
    Stream<T> s, BiFunction<? super T, ? super T, ? extends T> f) {
    return s.reduce(f::apply);
}

---

创建BinaryOperator 和UnaryOperator 最可能的原因是为了与这些没有超级接口的函数的原始类型版本对称。

在这方面，方法是一致的

• Stream.reduce(BinaryOperator<T>)
• IntStream.reduce(IntBinaryOperator)
• DoubleStream.reduce(DoubleBinaryOperator)
• LongStream.reduce(LongBinaryOperator)

或

• Arrays.parallelPrefix(T[] array, BinaryOperator<T> op)
• Arrays.parallelPrefix(int[] array, IntBinaryOperator op)
• Arrays.parallelPrefix(double[] array, DoubleBinaryOperator op)
• Arrays.parallelPrefix(long[] array, LongBinaryOperator op)

Answer 2

BinaryOperator<U> mergeFunction 需要从输入源获取Us 并将它们放入另一个消费者。

由于 Get 和 Put 原则，类型必须完全相同。没有通配符。

get-put 原则，如Naftalin and Wadler's fine book on generics, Java Generics and Collections 所述：

当您只从结构中获取值时使用扩展通配符，当您只将值放入结构时使用超级通配符，当您同时执行这两种操作时不要使用通配符。

因此它不能是BiFunction<? super U,? super U,? extends U> mergefunction，因为我们正在进行get 和put 操作。因此输入和结果类型必须相同。

有关 Get 和 Put 的更多信息，请参阅这些其他链接：

Explanation of the get-put principle（所以问题）

http://www.ibm.com/developerworks/library/j-jtp07018/

编辑

正如 Gab 所指出的，Get 和 Put 原则也被称为“生产者扩展消费者超级”的首字母缩写词 PECS

What is PECS (Producer Extends Consumer Super)?

Answer 3

查看有问题的Collectors#toMap 的实现，可以看到运算符被传递给其他一些方法，但最终仅以Map#merge(K key, V value, BiFunction<? super V,? super V,? extends V> remappingFunction) 的各种形式到达remappingFunction。

所以使用BiFunction<? super V, ? super V, ? extends V> 而不是BinaryOperator<V> 确实可以在这里工作，不会造成任何问题。但不仅在这里：BinaryOperator 只是BiFunction 的特化，用于操作数和结果都是相同类型的情况。所以有很多地方可以允许传入BiFunction<? super V, ? super V, ? extends V>而不是BinaryOperator<V>（或者，更明显的是：可以总是使用BiFunction<V, V, V>代替...)

---

所以到目前为止，他们选择只支持BinaryOperator<U> 似乎没有技术原因。

已经有关于可能的非技术原因的猜测。例如，限制方法签名的复杂性。我不确定这是否适用于这里，但它确实可能是方法的复杂性和预期的应用案例之间的权衡：“二元运算符”的概念很容易理解，例如，通过绘制在这种情况下，类似于简单的 addition 或两个集合的并集 - 或 maps。

一个可能不那么明显的技术原因可能是应该有可能提供此方法的实现，而该方法在内部无法处理BiFunction。但是考虑到BinaryOperator 只是一个专业化，很难想象这样的实现应该是什么样子。