Skip to content

Commit 941129c

Browse files
authored
Update 06_Wildcards_Versus_Type_Parameters.md
1 parent 6945b01 commit 941129c

File tree

1 file changed

+3
-3
lines changed

1 file changed

+3
-3
lines changed

ch02/06_Wildcards_Versus_Type_Parameters.md

+3-3
Original file line numberDiff line numberDiff line change
@@ -77,12 +77,12 @@ assert !ints.containsAll(objs); // 编译报错
7777
最后两个测试是非法的,因为类型声明要求我们只能测试一个列表是否包含该列表的一个子类型的元素。所以我们可以检查一个对象列表是否包含整数列表,而不是相
7878
反。
7979

80-
两种风格中哪一种更好是味道的问题。第一个允许更多的测试,第二个在编译时捕获更多的错误(同时排除一些明显的测试)。 `Java` 库的设计者选择了第一种更自由
81-
的替代方案,因为在泛型之前使用集合框架的人可能已经编写了诸如 `ints.containsAll(objs)` 之类的测试,并且该人希望该测试在泛型之后保持有效被添加到
80+
两种风格中哪一种更好是的实现的问题。第一个允许更多的测试,第二个在编译时捕获更多的错误(同时排除一些明显的测试)。 `Java` 库的设计者选择了第一种更自
81+
由的替代方案,因为在泛型之前使用集合框架的人可能已经编写了诸如 `ints.containsAll(objs)` 之类的测试,并且该人希望该测试在泛型之后保持有效被添加到
8282
`Java`。但是,在设计新的通用库(如 `MyCollection` )时,如果向后兼容性不太重要,那么在编译时捕获更多错误的设计可能更有意义。
8383

8484
可以说,核心包设计师做出了错误的选择。很少需要像 `ints.containsAll(objs)` 这样的测试,而且这样的测试仍然可以通过声明 `int` 具有 `List<Object>`
85-
型而不是 `List<Integer>` 类型来允许。在普通情况下捕捉更多的错误可能会更好,而不是允许在一个不常见的情况下进行更精确的打字
85+
型而不是允许 `List<Integer>` 类型。在普通情况下捕捉更多的错误可能会更好,而不是允许在一个不常见的情况下进行更精确的实现
8686

8787
同样的设计选择适用于包含 `Object``Collection<?>` 的其他方法。在他们的签名中,如 `remove``removeAll``retainAll`
8888

0 commit comments

Comments
 (0)