为什么许多Java流接口方法在参数中使用下界通配符而不是泛型类型？

Question

许多Java流接口方法在参数中使用下界通配符

例如

Stream<T> filter(Predicate<? super T> pred)

和

void forEach(Consumer<? super T> action)

使用谓词有什么好处

我明白，用谓语




Answer 1

我假设您知道PECS模式，这在设计应用编程接口时是有用的，即使没有实际的用例跳到您的眼睛里。当我们看到Java的最终状态

Stream.of("a", "b", "c").filter(Predicate.isEqual("b"));

需要过滤器（谓词

我们可能会认为Stream API的开发和新的Java语言版本/编译器实现是同时发生的，所以一开始使用PECS模式可能有一个实际的原因，而从来没有一个原因不要使用那种模式。它仍然提高了重用现有谓词、函数或消费者实例的灵活性，即使这可能不太常见，也没什么坏处。

注意，虽然，例如Stream.of（10,12.5）. filter（n-

Predicate<Number> name = n -> n.doubleValue()>=10;
Stream.of(10, 12.5).filter(name);

只有当filter被声明为filter（谓词）时，才有效

Predicate<Number> name = n -> n.doubleValue()>=10;
Stream.<Number>of(10, 12.5).filter(name);

这已经说明了如何省略？过滤器声明中的super可能会导致调用方更加冗长。此外，如果在以后的管道阶段需要更具体的元素类型，则强制使用更通用的元素类型可能不是一个选项。

虽然现有的函数实现很少，但也有一些，例如。

Stream.Builder<Number> b = Stream.builder();
IntStream.range(0, 10).boxed().forEach(b);
LongStream.range(0, 10).boxed().forEach(b);
Stream<Number> s = b.build();

没有<代码>就不能工作？super在forEach（消费者）中

您可能更经常遇到的一种情况是，有一个现有的比较器实现，您可能希望将其传递给具有更具体元素类型的流的排序方法，例如，

Stream.of("FOO", "bar", "Baz")
      .sorted(Collator.getInstance())
      .forEachOrdered(System.out::println);

没有<代码>就不能工作？super在排序（比较器）中