Java Generics

1. The introduction of the concept of generics (why are generics needed)?

First, let’s take a look at the following short code:

public class GenericTest {

    public static void main(String[] args) {
        List list = new ArrayList();
        list.add("qqyumidi");
        list.add("corn");
        list.add(100);

        for (int i = 0; i < list.size(); i++) {
            String name = (String) list.get(i); // 1
            System.out.println("name:" + name);
        }
    }
}

defines a collection of List type, first adds two string type values ​​to it, and then adds an Integer type value. This is completely allowed, because the default type of list is Object. In subsequent loops, errors similar to //1 may easily occur due to forgetting to add Integer type values ​​to the list before or for other encoding reasons. Because the compilation phase is normal, but a "java.lang.ClassCastException" exception occurs during runtime. Therefore, such errors are difficult to detect during coding.

During the above coding process, we found that there are two main problems:

1. When we put an object into the collection, the collection will not remember the type of the object. When the object is taken out from the collection again , the compiled type of the object is changed to the Object type, but its runtime type is still its own type.

2. Therefore, when taking out the collection elements at //1, artificial forced type conversion to a specific target type is required, and the "java.lang.ClassCastException" exception is prone to occur.

So is there any way to enable a collection to remember the types of elements in the collection, so that as long as there are no problems during compilation, "java.lang.ClassCastException" exceptions will not occur during runtime? The answer is to use generics.

2. What are generics?

Generics, that is, "parameterized types". When it comes to parameters, the most familiar thing is that there are formal parameters when defining a method, and then the actual parameters are passed when the method is called. So how do you understand parameterized types? As the name suggests, the type is parameterized from the original specific type, similar to the variable parameters in the method. At this time, the type is also defined in the form of a parameter (which can be called a type parameter), and then the specific type is passed in when using/calling type (type argument).

It seems a bit complicated. First, let’s take a look at the generic way of writing the example above.

public class GenericTest {

    public static void main(String[] args) {
        /*
        List list = new ArrayList();
        list.add("qqyumidi");
        list.add("corn");
        list.add(100);
        */

        List<String> list = new ArrayList<String>();
        list.add("qqyumidi");
        list.add("corn");
        //list.add(100);   // 1  提示编译错误

        for (int i = 0; i < list.size(); i++) {
            String name = list.get(i); // 2
            System.out.println("name:" + name);
        }
    }
}

After adopting the generic writing method, a compilation error will occur when trying to add an Integer type object at //1. Through List, it is directly limited to the list collection that can only contain String type elements, thus / There is no need to perform forced type conversion at /2, because at this time, the collection can remember the type information of the element, and the compiler can already confirm that it is of type String.

Combined with the above generic definition, we know that in List, String is a type actual parameter, that is to say, the corresponding List interface must contain type parameters. And the return result of the get() method is also directly the type of this formal parameter (that is, the corresponding incoming type actual parameter). Let’s take a look at the specific definition of the List interface:

public interface List<E> extends Collection<E> {

    int size();

    boolean isEmpty();

    boolean contains(Object o);

    Iterator<E> iterator();

    Object[] toArray();

    <T> T[] toArray(T[] a);

    boolean add(E e);

    boolean remove(Object o);

    boolean containsAll(Collection<?> c);

    boolean addAll(Collection<? extends E> c);

    boolean addAll(int index, Collection<? extends E> c);

    boolean removeAll(Collection<?> c);

    boolean retainAll(Collection<?> c);

    void clear();

    boolean equals(Object o);

    int hashCode();

    E get(int index);

    E set(int index, E element);

    void add(int index, E element);

    E remove(int index);

    int indexOf(Object o);

    int lastIndexOf(Object o);

    ListIterator<E> listIterator();

    ListIterator<E> listIterator(int index);

    List<E> subList(int fromIndex, int toIndex);
}

We can see that after adopting the generic definition in the List interface, the E in represents the type parameter and can receive specific type actual parameters. , and in this interface definition, wherever E appears, it represents the same type of actual parameters received from the outside.

Naturally, ArrayList is the implementation class of the List interface, and its definition form is:

public class ArrayList<E> extends AbstractList<E> 
        implements List<E>, RandomAccess, Cloneable, java.io.Serializable {
    
    public boolean add(E e) {
        ensureCapacityInternal(size + 1);  // Increments modCount!!
        elementData[size++] = e;
        return true;
    }
    
    public E get(int index) {
        rangeCheck(index);
        checkForComodification();
        return ArrayList.this.elementData(offset + index);
    }
    
    //...省略掉其他具体的定义过程

}

From this, we understand from the source code perspective why there is a compilation error when adding an Integer type object at //1, and get( at //2 ) is directly the String type.

3. Customized generic interfaces, generic classes and generic methods

From the above content, everyone has understood the specific operation process of generics. We also know that interfaces, classes and methods can also be defined using generics and used accordingly. Yes, in specific use, it can be divided into generic interfaces, generic classes and generic methods.

Customized generic interfaces, generic classes and generic methods are similar to List and ArrayList in the above Java source code. As follows, we look at the simplest definition of generic classes and methods:

public class GenericTest {

    public static void main(String[] args) {

        Box<String> name = new Box<String>("corn");
        System.out.println("name:" + name.getData());
    }

}

class Box<T> {

    private T data;

    public Box() {

    }

    public Box(T data) {
        this.data = data;
    }

    public T getData() {
        return data;
    }

}

In the definition process of generic interfaces, generic classes and generic methods, we commonly use parameters in the form of T, E, K, V, etc. It is often used to represent generic parameters because it receives type arguments passed in from external uses. So for different type arguments passed in, are the types of the corresponding object instances generated the same?

public class GenericTest {

    public static void main(String[] args) {

        Box<String> name = new Box<String>("corn");
        Box<Integer> age = new Box<Integer>(712);

        System.out.println("name class:" + name.getClass());      // com.qqyumidi.Box
        System.out.println("age class:" + age.getClass());        // com.qqyumidi.Box
        System.out.println(name.getClass() == age.getClass());    // true

    }

}

From this, we found that when using generic classes, although different generic arguments are passed in, different types are not actually generated. Generic classes that pass in different generic arguments are There is only one in the memory, which is the original most basic type (Box in this example). Of course, logically we can understand it as multiple different generic types.

The reason is that the purpose of the concept of generics in Java is that it only acts on the code compilation stage. During the compilation process, after the generic results are correctly checked, the relevant information of the generics will be erased. , that is to say, the successfully compiled class file does not contain any generic information. Generic information does not enter the runtime stage.

This can be summed up in one sentence: Generic types can be viewed logically as multiple different types, but in fact they are all the same basic type.

4. Type wildcard

接着上面的结论，我们知道，Box和Box实际上都是Box类型，现在需要继续探讨一个问题，那么在逻辑上，类似于Box和Box是否可以看成具有父子关系的泛型类型呢？

为了弄清这个问题，我们继续看下下面这个例子:

public class GenericTest {

    public static void main(String[] args) {

        Box<Number> name = new Box<Number>(99);
        Box<Integer> age = new Box<Integer>(712);

        getData(name);
        
        //The method getData(Box<Number>) in the type GenericTest is 
        //not applicable for the arguments (Box<Integer>)
        getData(age);   // 1

    }
    
    public static void getData(Box<Number> data){
        System.out.println("data :" + data.getData());
    }

}

我们发现，在代码//1处出现了错误提示信息：The method getData(Box) in the t ype GenericTest is not applicable for the arguments (Box)。显然，通过提示信息，我们知道Box在逻辑上不能视为Box的父类。那么，原因何在呢？

public class GenericTest {

    public static void main(String[] args) {

        Box<Integer> a = new Box<Integer>(712);
        Box<Number> b = a;  // 1
        Box<Float> f = new Box<Float>(3.14f);
        b.setData(f);        // 2

    }

    public static void getData(Box<Number> data) {
        System.out.println("data :" + data.getData());
    }

}

class Box<T> {

    private T data;

    public Box() {

    }

    public Box(T data) {
        setData(data);
    }

    public T getData() {
        return data;
    }

    public void setData(T data) {
        this.data = data;
    }

}

这个例子中，显然//1和//2处肯定会出现错误提示的。在此我们可以使用反证法来进行说明。

假设Box在逻辑上可以视为Box的父类，那么//1和//2处将不会有错误提示了，那么问题就出来了，通过getData()方法取出数据时到底是什么类型呢？Integer? Float? 还是Number？且由于在编程过程中的顺序不可控性，导致在必要的时候必须要进行类型判断，且进行强制类型转换。显然，这与泛型的理念矛盾，因此，在逻辑上Box不能视为Box的父类。

好，那我们回过头来继续看“类型通配符”中的第一个例子，我们知道其具体的错误提示的深层次原因了。那么如何解决呢？总部能再定义一个新的函数吧。这和Java中的多态理念显然是违背的，因此，我们需要一个在逻辑上可以用来表示同时是Box和Box的父类的一个引用类型，由此，类型通配符应运而生。

类型通配符一般是使用 ? 代替具体的类型实参。注意了，此处是类型实参，而不是类型形参！且Box>在逻辑上是Box、Box...等所有Box的父类。由此，我们依然可以定义泛型方法，来完成此类需求。

public class GenericTest {

    public static void main(String[] args) {

        Box<String> name = new Box<String>("corn");
        Box<Integer> age = new Box<Integer>(712);
        Box<Number> number = new Box<Number>(314);

        getData(name);
        getData(age);
        getData(number);
    }

    public static void getData(Box<?> data) {
        System.out.println("data :" + data.getData());
    }

}

有时候，我们还可能听到类型通配符上限和类型通配符下限。具体有是怎么样的呢？

在上面的例子中，如果需要定义一个功能类似于getData()的方法，但对类型实参又有进一步的限制：只能是Number类及其子类。此时，需要用到类型通配符上限。

public class GenericTest {

    public static void main(String[] args) {

        Box<String> name = new Box<String>("corn");
        Box<Integer> age = new Box<Integer>(712);
        Box<Number> number = new Box<Number>(314);

        getData(name);
        getData(age);
        getData(number);
        
        //getUpperNumberData(name); // 1
        getUpperNumberData(age);    // 2
        getUpperNumberData(number); // 3
    }

    public static void getData(Box<?> data) {
        System.out.println("data :" + data.getData());
    }
    
    public static void getUpperNumberData(Box<? extends Number> data){
        System.out.println("data :" + data.getData());
    }

}

此时，显然，在代码//1处调用将出现错误提示，而//2 //3处调用正常。

类型通配符上限通过形如Box extends Number>形式定义，相对应的，类型通配符下限为Box super Number>形式，其含义与类型通配符上限正好相反，在此不作过多阐述了。

 

五.话外篇

本文中的例子主要是为了阐述泛型中的一些思想而简单举出的，并不一定有着实际的可用性。另外，一提到泛型，相信大家用到最多的就是在集合中，其实，在实际的编程过程中，自己可以使用泛型去简化开发，且能很好的保证代码质量。并且还要注意的一点是，Java中没有所谓的泛型数组一说。

对于泛型，最主要的还是需要理解其背后的思想和目的。

更多Java泛型相关文章请关注PHP中文网！