ITEM 31: USE BOUNDED WILDCARDS TO INCREASE API FLEXIBILITY
如 item 28 所述，参数化类型是不变的。换句话说，对于任何两种类型 Type1 和Type2， List
public class Stack {
public Stack();
public void push(E e);
public E pop();
public boolean isEmpty();
}
假设我们想添加一个方法，它接受一系列元素并将它们全部推入堆栈。这是第一次尝试:
// pushAll method without wildcard type - deficient!
public void pushAll(Iterable src) {
for (E e : src)
push(e);
}
这种方法编译得很干净，但并不完全令人满意。如果 Iterable src 的元素类型与堆栈的元素类型完全匹配，则可以正常工作。但是假设您有一个 Stack
Stack numberStack = new Stack<>();
Iterable integers = ... ;
numberStack.pushAll(integers);
但是，如果您尝试它，您将得到这个错误消息，因为参数化类型是不变的:
“StackTest.java:7: error: incompatible types: Iterable
幸运的是，有一条出路。Java语言提供了一种特殊的参数化类型，使用有界通配符类型来处理这种情况。pushAll 的输入参数类型不应该是“Iterable of E”，而应该是“E的某个子类型的 Iterable”，并且有一个通配符类型，它的确切含义是: Iterable。(关键字extends的使用有点误导人:回顾 item 29，定义了子类型，因此每个类型都是自身的子类型，即使它不扩展自己。)让我们修改 pushAll 来使用这个类型:
// Wildcard type for a parameter that serves as an E producer
public void pushAll(Iterable src) {
for (E e : src)
push(e);
}
有了这个更改，不仅 Stack 可以顺利地编译，而且无法使用原始 pushAll 声明编译的客户机代码也可以。因为Stack和它的客户机编译得很干净，所以您知道所有东西都是类型安全的。
现在假设您想编写一个 popAll 方法。popAll 方法将每个元素从堆栈中取出，并将元素添加到给定的集合中。下面是第一次尝试编写 popAll 方法的样子:
public void popAll(Collection dst) {
while (!isEmpty())
dst.add(pop());
}
同样，如果目标集合的元素类型与堆栈的元素类型完全匹配，则可以干净地编译并正常工作。但同样，这并不完全令人满意。假设您有一个 Stack
Stack numberStack = new Stack();
Collection 如果您尝试根据前面显示的 popAll 版本编译此客户机代码，您将得到一个与我们在pushAll 的第一个版本中得到的错误非常相似的错误: “Collection
// Wildcard type for parameter that serves as an E consumer
public void popAll(Collection dst) {
while (!isEmpty())
dst.add(pop());
}
通过此更改，Stack 和客户机代码都可以干净地编译。教训很明显。为了获得最大的灵活性，对表示生产者或消费者的输入参数使用通配符类型。如果输入参数同时是生产者和消费者，那么通配符类型对您没有任何好处: 您需要精确的类型匹配，这是在没有通配符的情况下得到的。下面是一个助记符，帮助您记住使用哪种通配符类型:
" PECS stands for producer-extends, consumer-super. "
换句话说，如果参数化类型表示一个 T 生产者，那么使用 ；如果它表示一个 T 消费者，使用 。在我们的堆栈示例中，pushAll 的 src参数生成供堆栈使用的 E 实例，因此 src 的适当类型是 Iterable；popAll 的 dst参数使用堆栈中的 E 个实例，因此 dst 的类型应当是 Collection。PECS助记符捕获了指导通配符类型使用的基本原则。Naftalin和Wadler将其称为Get and Put原则[Naftalin 07,2.4]。
记住这个助记符之后，让我们看看本章前面几项中的一些方法和构造函数声明。
item 28中的 Chooser 构造函数有如下声明:
public Chooser(Collection
这个构造函数只使用集合选项来生成 T 类型的值(并将它们存储起来供以后使用)，因此它的声明应该使用扩展T的通配符类型。下面是生成的构造函数声明:
// Wildcard type for parameter that serves as an T producer
public Chooser(Collection choices)
这种改变在实践中会有什么不同吗？是的，它会。假设您有一个列表，您希望将它传递给选择器的构造函数。这将不会使用原始声明编译，但是一旦将有界通配符类型添加到声明中，就会编译。
现在让我们看看item 30中的 union 方法。声明如下:
public static
参数 s1 和 s2 都是E生产者，因此 PECS 助记符告诉我们声明应该如下:
public static
注意，返回类型仍然设置为 Set
Set integers = Set.of(1, 3, 5);
Set doubles = Set.of(2.0, 4.0, 6.0);
Set numbers = union(integers, doubles);
如果使用得当，通配符类型对类的用户几乎是不可见的。它们使得方法接受它们应该接受的参数，并拒绝它们应该拒绝的参数。如果类的用户必须考虑通配符类型，那么它的API可能有问题。
在Java 8之前，类型推断规则还不足以处理前面的代码片段，这要求编译器使用上下文指定的返回类型(或目标类型)来推断e的类型。前面显示的 union 调用的目标类型设置为 Set
“Union.java:14: error: incompatible types
Set
required: Set
found: Set
where INT#1,INT#2 are intersection types:
INT#1 extends Number,Comparable INT#2 extends Number,Comparable”
幸运的是，有一种方法可以处理这种错误。如果编译器没有推断出正确的类型，您总是可以通过显式类型参数[JLS, 15.12]告诉它使用哪种类型。甚至在Java 8中引入目标类型之前，您也不需要经常这样做，这很好，因为显式类型参数不是很漂亮。通过添加显式类型参数(如下所示)，代码片段可以在Java 8之前的版本中干净地编译:
// Explicit type parameter - required prior to Java 8
Set numbers = Union.union(integers, doubles);
接下来，让我们将注意力转向 item 30中的 max 方法。以下是原始声明:
public static
下面是使用通配符类型的修订声明:
public static
为了从原来的声明中得到修改后的声明，我们使用了两次 PECS 启发式。最简单的应用程序是参数列表。它生成了T个实例，所以我们将类型从 List
修订后的max声明可能是本书中最复杂的方法声明。增加的复杂性真的能给你带来什么好处吗? 再一次，是的。以下是一个简单的列表例子，原声明将排除该列表，但修订后的声明允许该列表:
List
不能将原始方法声明应用于此列表的原因是 ScheduledFuture 没有实现 Comparable
还有一个与通配符相关的主题值得讨论。类型参数和通配符之间存在对偶性，可以使用其中一个或另一个声明许多方法。例如，下面是静态方法的两种可能声明，用于交换列表中两个索引项。第一个使用无界类型参数(Item 30)，第二个使用无界通配符:
// Two possible declarations for the swap method
public static void swap(List list, int i, int j);
public static void swap(List list, int i, int j);
这两个声明中哪一个更好，为什么?
在公共API中，第二个更好，因为它更简单。您传入一个列表—任何列表—该方法交换索引元素。没有需要担心的类型参数。通常，如果类型参数在方法声明中只出现一次，则使用通配符替换它。如果是无界类型参数，则使用无界通配符替换它;如果是有界类型参数，则使用有界通配符替换它。
swap的第二个声明有一个问题。简单的实现无法编译:
public static void swap(List list, int i, int j) {
list.set(i, list.set(j, list.get(i)));
}
试图编译它会产生这样一个无益的错误信息:
"Swap.java:5: error: incompatible types: Object cannot be converted to CAP#1
list.set(i, list.set(j, list.get(i)));
where CAP#1 is a fresh type-variable: CAP#1 extends Object from capture of ?"
我们不能把一个元素放回我们刚取出来的列表中，这似乎是不对的。问题是list的类型lList，您不能将除null之外的任何值放入列表。幸运的是，有一种方法可以实现这种方法，而不用使用不安全的强制转换或原始类型。其思想是编写一个私有helper方法来捕获通配符类型。为了捕获类型，helper方法必须是泛型方法。它是这样的:
public static void swap(List list, int i, int j) {
swapHelper(list, i, j);
}
// Private helper method for wildcard capture
private static void swapHelper(List list, int i, int j) {
list.set(i, list.set(j, list.get(i)));
}
swapHelper 方法知道 list 是一个 List
总之，在api中使用通配符类型虽然很棘手，但会使api更加灵活。如果您编写的库将被广泛使用，应该认为必须正确使用通配符类型。记住基本规则: producer-extends， consumer-super (PECS)。还要记住，所有比较对象和比较器都是消费者。