Java范型那些事（二）
接上篇博文
《Java范型那些事（一）》
参考oracle官网对于范型的介绍 ： https://docs.oracle.com/javase/tutorial/extra/generics/legacy.html
目录
9. 使用通配符？的更多乐趣
通配符捕获
10. 使用范型改写旧代码（未使用范型的代码）
9. 使用通配符？的更多乐趣
在这一节，我们将考虑通配符的更多高级用法。在前面几节的介绍中，我们已经看到了几个例子，当从数据结构中读取时，有界通配符很有用。现在考虑相反的情况，一种只写数据结构。接口Sink就是这种简单的例子。
interface Sink {
flush(T t);
} 我们可以想象通过如下面的代码所示来使用它。方法writeAll（）旨在将集合coll的所有元素刷新到sink snk，并返回刷新的最后一个元素。
public static T writeAll(Collection coll, Sink snk) {
T last;
for (T t : coll) {
last = t;
snk.flush(last);
}
return last;
}
...
Sink 如上所述，对writeAll（）的调用是非法的，因为不能推断出有效的类型参数; String和Object都不是T的合适类型，因为Collection元素和Sink元素必须是同一类型。
我们可以通过使用通配符修改writeAll（）的签名来修复此错误，如下所示。
public static T writeAll(Collection, Sink) {...}
...
// 调用正常，但返回类型错误
String str = writeAll(cs, s); 调用现在是合法的，但是赋值是错误的，因为推断的返回类型是Object，因为T匹配s的元素类型，即Object。
解决方案是使用一种我们尚未见过的有界通配符形式：具有下限的通配符。语法？ super T表示一个未知类型，它是T的超类型（或T本身;记住超类型关系是自反的）。这是我们使用的有界通配符的双重性——我们使用“？extends T”表示作为T的子类型的未知类型。
public static T writeAll(Collection coll, Sink snk) {
...
}
String str = writeAll(cs, s); // Yes! 使用此语法，调用是合法的，并且推断的类型为String，和期望一致。
现在让我们转向一个更现实的例子。 java.util.TreeSet
TreeSet(Comparator c) Comparator接口实质上是：
interface Comparator {
int compare(T fst, T snd);
} 假设我们想要创建一个TreeSet
TreeSet(Comparator c) 以上代码允许使用任何适用的Comparator。
作为使用下边界通配符的最后一个示例，让我们看一下Collections.max（）方法，它返回作为参数传递给它的集合中的最大元素。现在，为了使max（）工作，传入的集合的所有元素都必须实现Comparable。此外，它们必须彼此具有可比性。
首次尝试生成此方法签名会产生：
public static > T max(Collection coll) 也就是说，该方法接收一个能与自身相比的某种类型T的集合，并返回该类型的元素。但是，此代码过于严格。要了解原因，请考虑与任意对象相比较的一种类型：
class Foo implements Comparablecf的每个元素都能与cf中的其他元素相比较，因为每个这样的元素都是Foo类型。但是，使用上面的签名，我们发现该调用被拒绝。推断类型必须是Foo，但Foo并没有实现Comparable
T不必与其本身相比较。所需要的只是T与其超类型之一能相互比较。这告诉我们：
public static >
T max(Collection coll) 请注意，Collections.max（）的实际签名更复杂。我们将在下一节“将旧版代码转换为使用泛型”中再提到它。这种推理适用于几乎任何用于任意类型的Comparable的用法：你总是想使用Comparable <？super T>。
⚠️总结：通常，如果您的API仅使用类型参数T作为参数，则其使用应该利用较低的有界通配符（？super T）。相反，如果API仅返回T，您将通过使用上限有通配符（？extends T）为您的客户提供更大的灵活性。
通配符捕获
现在应该很清楚，给定：
Set unknownSet = new HashSet();
...
/* Add an element t to a Set s. */
public static void addToSet(Set s, T t) {
...
} 以下调用是非法的。
addToSet(unknownSet, "abc"); // Illegal.传递的实际集合是一组字符串没有区别;重要的是，作为参数传递的表达式是一组未知类型，不能保证是一组字符串，特别是任何类型的字符串。
现在，请考虑以下代码：
class Collections {
...
public static Set unmodifiableSet(Set set) {
...
}
}
...
Set s = Collections.unmodifiableSet(unknownSet); // This works! Why? 这似乎不应该被允许;但是，看看这个特定的调用，允许它是完全安全的。毕竟，unmodifiableSet（）适用于任何类型的Set，无论其元素类型如何。
因为这种情况相对频繁地出现，所以有一个特殊的规则允许在非常特定的情况下使用这些代码，在这种情况下代码可以被证明是安全的。此规则称为通配符捕获，允许编译器将通配符的未知类型推断为泛型方法的类型参数。
10. 使用范型改写旧代码（未使用范型的代码）
之前，我们展示了新旧代码如何互操作。 现在，是时候看看“泛化”旧代码的难题了。
如果您决定将旧代码转换为使用泛型，则需要仔细考虑如何修改API。
您需要确保修改后的范型API不会有过度的限制; 它必须继续支持API的原始约定。 再次考虑java.util.Collection中的一些示例。 没有使用范型之前的API如下所示：
interface Collection {
public boolean containsAll(Collection c);
public boolean addAll(Collection c);
}初次尝试使用范型改写后，可能会像下面这样：
interface Collection {
public boolean containsAll(Collection c);
public boolean addAll(Collection c);
} 虽然这显然是类型安全的，但也符合API的原始规定。 containsAll（）方法适用于任何类型的传入集合。只有当传入的集合实际上只包含E的实例时，它才会成功，但是：
- 传入集合的静态类型可能不同，可能是因为调用者不知道传入的集合的精确类型，或者可能是因为它是Collection
，其中S是E的子类型。 - 使用一个不同类型的集合作为参数，传入containsAll（）是完全合法的。按照期望应该能调用，然后返回false。
在addAll（）的情况下，我们应该能够添加由E子类型的实例组成的任何集合。我们在范型方法部分中看到了如何正确处理这种情况。
您还需要确保修订后的API保留与旧客户端的代码兼容性。这意味着API的擦除范型类型后，必须与原始的、未使用范型的API相同。在大多数情况下，这自然会失败，但有一些微妙的情况。我们将研究我们遇到过的最微妙的案例之一，即Collections.max（）方法。正如我们在第9节，使用通配符更多乐趣部分中看到的，max（）的一个合理签名是：
public static >
T max(Collection coll) 代码看上去很好，除了在擦除范型类型后，是这样的：
public static Comparable max(Collection coll)但这与max（）的原始签名不同：
public static Object max(Collection coll)当然可以为max（）指定此签名，但是没有完成，并且调用Collections.max（）的所有旧类文件都依赖于返回Object的签名。
我们可以通过在形式类型参数T的边界中显式指定一个超类，来强制使得类型擦除跟上面的不一样。
public static >
T max(Collection coll) 这是使用语法T1和T2 ...＆Tn为类型参数赋予多个边界的示例。 具有多个边界的类型变量，是边界中列出的所有类型的子类型。 当使用多边界时，边界中提到的第一种类型用作类型变量的擦除。
最后，我们应该记得max只读取其输入集合，因此适用于T的任何子类型的集合。
这将我们带到JDK中使用的实际签名：
public static >
T max(Collection coll) 在实践中出现任何如此复杂的事情是非常罕见的，但专业library设计师应该在使用范型转换现有API时仔细考虑。
需要注意的另一个问题是协变返回，即改进子类中方法的返回类型。 您不应该在旧API中利用此功能。 为了了解原因，让我们看一个例子。
假设您的原始API具有以下形式：
public class Foo {
// Factory. Should create an instance of
// whatever class it is declared in.
public Foo create() {
...
}
}
public class Bar extends Foo {
// Actually creates a Bar.
public Foo create() {
...
}
}
为了利用协变返回的优势，你可以将它修改为：
public class Foo {
// Factory. Should create an instance of
// whatever class it is declared in.
public Foo create() {
...
}
}
public class Bar extends Foo {
// Actually creates a Bar.
public Bar create() {
...
}
}现在假设你代码中的一个第三方客户端编写了一下代码：
public class Baz extends Bar {
// Actually creates a Baz.
public Foo create() {
...
}
}Java虚拟机不直接支持覆盖具有不同返回类型的方法。 此功能是由编译器来支持。 因此，除非重新编译Baz类，否则它将无法正确覆盖Bar的create（）方法。 此外，Baz必须被修改，因为代码将被写入拒绝 - Baz中的create（）的返回类型不是Bar中返回类型create（）的子类型。
更多关于Java的协变、逆变和不变的介绍，可以参考我的另外一篇博客：Kotlin笔记12-Java和Kotlin中的范型对比（一）