相关疑难解决方法(0)

如果我编写Predicate接口,我想在接口中编码它只是一个返回原始布尔值的函数,如下所示:

@FunctionalInterface
public interface Predicate<T> extends Function<T, Boolean> {

    boolean test(T t);

    @Override
    default Boolean apply(T t) {
        return Boolean.valueOf(test(t));
    }
}

我想知道,有没有令人信服的理由让Java 8 API设计者选择将Predicate与Function完全分开？是否有一些证据表明他们认为这样做并决定反对呢？我想类似的问题适用于所有其他'特殊'功能接口,如Consumer(可能是Function <T,Void>),Supplier(Function <Void,T>)和原始函数,如IntFunction(Function <Integer,T>).

我没有深入和彻底地考虑过这个问题的所有后果,所以我可能会遗漏一些东西.

编辑:一些答案强调了应用和测试之间的语义区别.我不是说我不欣赏这种区别,我同意这种区别是有益的.我不明白的是,为什么Predicate不是一个函数,就像List是一个Collection或Double是一个Number,它是一个Object.

如果Predicate(以及所有其他特殊的通用功能接口,例如Consumer,Supplier,IntUnaryOperator等)与Function有这种关系,它将允许人们在预期使用Function参数的地方使用它(想到的是组合与其他功能,例如,呼叫myFunction.compose(比如说myPredicate)或避免在API中写入几个专门的功能时,如上所述的这种汽车(未)拳击实施将是足够的)

编辑2:看看openjdk lambda项目,我发现原始的功能接口用于扩展功能,直到2012-12-19的Brian Goetz提交.我找不到具体的原因,在那个时候对任何lambda-dev或JSR专家组邮件列表进行了更改.

这与为什么 Java 8 的 ToIntFunction 不扩展 Function<T, Integer> 相关

我觉得有点烦人的是， 的原始版本Optional和各种功能接口使用不同的方法名称，例如getAsInt()代替get()和applyAsDouble(x, y)代替apply(x, y)。我想知道为什么他们不使用相同的方法名称。毕竟，所有流都使用map、filter、reduce等，而不管类型如何，这似乎很有意义。拥有doubles.filterDoubles(DoublePredicate)and似乎没有意义ints.reduceAsInt(IntBinaryOperator)。但是我们为什么要这样做ints.reduce(Integer::sum).getAsInt()呢？

特别是，注意到不对称性很有趣。两者ints.reduce(...).get()和ints.reducePrimitive(...).getAsPrimitive()将是一致的。然而我们两者都没有。

我能想到的一个原因是想让继承成为可能。如果我们希望 anOptionalInt也成为 an Optional<Integer>，那么我们不能同时拥有 anint get()和 anInteger get()方法。因此，扩展Optional<Integer>，继承自动装箱方法，然后还添加一个额外的纯原始方法以避免性能自动装箱是有意义的。同样的想法也适用于函数。但正如上述问题所讨论的，原始函数接口不扩展泛型接口，原始 O​​ptional 类也不扩展。

有什么我没有看到的吗？会使用get和apply破坏某些东西吗？或者这只是 API 中的偶然不一致，类似于String.length()vs List.size()？我想设计者可能希望在将来使用上述继承敞开大门。谁能想到另一个原因？