Java泛型方法

1. 考虑一个编程问题：把数组中的元素都存入集合里面。如下是我们的第一次尝试：

static void fromArrayToCollection(Object[] a, Collection<?> c) {
    for (Object o : a) { 
        c.add(o); // compile-time error
    }
}

　　我们知道这样写是错的，你或许尝试过Collection<?>，同样不可行的。总之，我们不能强行向一个未知的集合里存放数据。

　　这种情况下，我们考虑使用泛型方法了。改进方法如下：

static <T> void fromArrayToCollection(T[] a, Collection<T> c) {
    for (T o : a) {
        c.add(o); // Correct
    }
}

　　同样，如果集合的元素类型是数组的元素类型的父类，我们也可以调用这个方法。如下：

Object[] objectArr= new Object[100];

Collection<Object> objectCollection= new ArrayList<Object>();

// T是Object类型
fromArrayToCollection(objectArr, objectCollection); 

String[] stringArr= new String[100];
Collection<String> stringCollection= new ArrayList<String>();

// T是String类型
fromArrayToCollection(stringArr, stringCollection);

// T 是 Object类型
fromArrayToCollection(stringArr, objectCollection);

/*
    错误，无法确定T的类型，
    T 是 String ? 那就相当于把 Object[] 赋值给了 String[] ，显然错误，
    T 是 Object ？ 那就相当于把 Collection<String> 赋值给了 Collection<Object>，显然也是错误的，

    注：Object[] a = new String[2];这是成立的
       List<Object> c = new ArrayList<String>();不成立
*/
fromArrayToCollection(objectArr,StringCollection);

Integer[] ia = new Integer[100];
Float[] fa = new Float[100];
Number[] na = new Number[100];
Collection<Number> cn = new ArrayList<Number>();

// T 是 Number
fromArrayToCollection(ia, cn);

// T 是 Number
fromArrayToCollection(fa, cn);

// T 是 Number
fromArrayToCollection(na, cn);

// T 是 Object
fromArrayToCollection(na, objectCollection);

// 编译错误
fromArrayToCollection(na, stringCollection);    

 

2. 什么时候用泛型方法，什么时候用通配符类型方法?

　　为了理解这个问题，我们先看看jdk api 中 Collection 库吧，如下：

interface Collection<E> {
    public boolean containsAll(Collection<?> c);
    public boolean addAll(Collection<? extends E> c);
}

　　我们用泛型替代上面的代码，如下：

interface Collection<E> {
    public <T> boolean containsAll(Collection<T> c);
    public <T extends E> boolean addAll(Collection<T> c);
}

 　　

　　However, in both containsAll and addAll, the type parameter T is used only once. The return type doesn't depend on the type parameter, nor does any other argument to the method (in this case, there simply is only one argument). This tells us that the type argument is being used for polymorphism; its only effect is to allow a variety of actual argument types to be used at different invocation sites. If that is the case, one should use wildcards. Wildcards are designed to support flexible subtyping, which is what we're trying to express here.

Generic methods allow type parameters to be used to express dependencies among the types of one or more arguments to a method and/or its return type. If there isn't such a dependency, a generic method should not be used.

It is possible to use both generic methods and wildcards in tandem. Here is the method Collections.copy():

class Collections {
    public static <T> void copy(List<T> dest, List<? extends T> src) {
    ...
}

Note the dependency between the types of the two parameters. Any object copied from the source list, src, must be assignable to the element type T of the destination list, dst. So the element type of src can be any subtype of T—we don't care which. The signature of copy expresses the dependency using a type parameter, but uses a wildcard for the element type of the second parameter.

We could have written the signature for this method another way, without using wildcards at all:

class Collections {
    public static <T, S extends T> void copy(List<T> dest, List<S> src) {
    ...
}

This is fine, but while the first type parameter is used both in the type of dst and in the bound of the second type parameter, S, S itself is only used once, in the type of src—nothing else depends on it. This is a sign that we can replace S with a wildcard. Using wildcards is clearer and more concise than declaring explicit type parameters, and should therefore be preferred whenever possible.

Wildcards also have the advantage that they can be used outside of method signatures, as the types of fields, local variables and arrays. Here is an example.

Returning to our shape drawing problem, suppose we want to keep a history of drawing requests. We can maintain the history in a static variable inside class Shape, and have drawAll()store its incoming argument into the history field.

static List<List<? extends Shape>> 
    history = new ArrayList<List<? extends Shape>>();

public void drawAll(List<? extends Shape> shapes) {
    history.addLast(shapes);
    for (Shape s: shapes) {
        s.draw(this);
    }
}

Finally, again let's take note of the naming convention used for the type parameters. We use T for type, whenever there isn't anything more specific about the type to distinguish it. This is often the case in generic methods. If there are multiple type parameters, we might use letters that neighbor T in the alphabet, such as S. If a generic method appears inside a generic class, it's a good idea to avoid using the same names for the type parameters of the method and class, to avoid confusion. The same applies to nested generic classes.