mirror of
https://github.com/sjsdfg/effective-java-3rd-chinese.git
synced 2025-01-17 07:40:09 +08:00
Update 44. 优先使用标准的函数式接口.md
This commit is contained in:
parent
b0ab1d937b
commit
11e0c820e4
@ -37,7 +37,7 @@ interface EldestEntryRemovalFunction<K,V>{
|
||||
|
||||
`Function` 接口还有九个额外的变体,当结果类型为基本类型时使用。 源和结果类型总是不同,因为从类型到它自身的函数是 `UnaryOperator`。 如果源类型和结果类型都是基本类型,则使用带有 `SrcToResult` 的前缀 `Function`,例如 `LongToIntFunction`(六个变体)。如果源是一个基本类型,返回结果是一个对象引用,那么带有 `ToObj` 的前缀 `Function`,例如 `DoubleToObjFunction` (三种变体)。
|
||||
|
||||
有三个包含两个参数版本的基本功能接口,使它们有意义`:BiPredicate <T,U>`,`BiFunction <T,U,R>` 和 `BiConsumer <T,U>`。 也有返回三种相关基本类型的 `BiFunction` 变体:`ToIntBiFunction <T,U>`,`ToLongBiFunction<T,U>` 和 `ToDoubleBiFunction <T,U>`。`Consumer` 有两个变量,它们带有一个对象引用和一个基本类型:`ObjDoubleConsumer <T>`,`ObjIntConsumer <T>` 和 `ObjLongConsumer <T>`。 总共有九个两个参数版本的基本接口。
|
||||
有三个包含两个参数版本的基本功能接口,使它们有意义:`BiPredicate <T,U>`,`BiFunction <T,U,R>` 和 `BiConsumer <T,U>`。 也有返回三种相关基本类型的 `BiFunction` 变体:`ToIntBiFunction <T,U>`,`ToLongBiFunction<T,U>` 和 `ToDoubleBiFunction <T,U>`。`Consumer` 有两个变量,它们带有一个对象引用和一个基本类型:`ObjDoubleConsumer <T>`,`ObjIntConsumer <T>` 和 `ObjLongConsumer <T>`。 总共有九个两个参数版本的基本接口。
|
||||
|
||||
最后,还有一个 `BooleanSupplier` 接口,它是 `Supplier` 的一个变体,它返回布尔值。 这是任何标准函数式接口名称中唯一明确提及的布尔类型,但布尔返回值通过 `Predicate` 及其四种变体形式支持。 前面段落中介绍的 `BooleanSupplier` 接口和 42 个接口占所有四十三个标准功能接口。 无可否认,这是非常难以接受的,并且不是非常正交的。 另一方面,你所需要的大部分功能接口都是为你写的,而且它们的名字是经常性的,所以在你需要的时候不应该有太多的麻烦。
|
||||
|
||||
@ -55,7 +55,7 @@ interface EldestEntryRemovalFunction<K,V>{
|
||||
|
||||
如果选择编写你自己的函数式接口,请记住它是一个接口,因此应非常小心地设计(条目 21)。
|
||||
|
||||
请注意,`EldestEntryRemovalFunction` 接口(第 199 页)`标有 @FunctionalInterface` 注解。 这种注解在类型类似于 `@Override`。 这是一个程序员意图的陈述,它有三个目的:它告诉读者该类和它的文档,该接口是为了实现 lambda 表达式而设计的;它使你保持可靠,因为除非只有一个抽象方法,否则接口不会编译; 它可以防止维护人员在接口发生变化时不小心地将抽象方法添加到接口中。 **始终使用@FunctionalInterface 注解标注你的函数式接口。**
|
||||
请注意,`EldestEntryRemovalFunction` 接口(第 199 页)`标有 @FunctionalInterface` 注解。 这种注解在类型类似于 `@Override`。 这是一个程序员意图的陈述,它有三个目的:它告诉读者该类和它的文档,该接口是为了实现 lambda 表达式而设计的;它使你保持可靠,因为除非只有一个抽象方法,否则接口不会编译; 它可以防止维护人员在接口发生变化时不小心地将抽象方法添加到接口中。 **始终使用 `@FunctionalInterface` 注解标注你的函数式接口。**
|
||||
|
||||
最后一点应该是关于在 api 中使用函数接口的问题。不要提供具有多个重载的方法,这些重载在相同的参数位置上使用不同的函数式接口,如果这样做可能会在客户端中产生歧义。这不仅仅是一个理论问题。`ExecutorService` 的 `submit` 方法可以采用 `Callable<T>` 或 `Runnable` 接口,并且可以编写需要强制类型转换以指示正确的重载的客户端程序 (条目 52)。避免此问题的最简单方法是不要编写在相同的参数位置中使用不同函数式接口的重载。这是条目 52 中建议的一个特例,“明智地使用重载”。
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user