Une explication détaillée des génériques Java

Présentation

Les génériques sont un point de connaissance très important en Java. Les génériques sont largement utilisés dans le framework de classes de collection Java. Dans cet article, nous examinerons la conception des génériques Java à partir de zéro, ce qui impliquera un traitement des caractères génériques et un effacement de type ennuyeux.

Bases génériques

Classe générique

​Nous définissons d'abord une classe Box simple :

public class Box {
    private String object;
    public void set(String object) { this.object = object; }
    public String get() { return object; }
}

C'est l'approche la plus courante. Un inconvénient est que seuls les éléments de type String peuvent être chargés dans Box maintenant. Si nous devons charger d'autres types d'éléments tels que Integer à l'avenir, nous devons réécrire une autre Box, et le code le fera. être compliqué. Lorsqu’il s’agit de réutilisation, l’utilisation de génériques peut très bien résoudre ce problème.

public class Box<T> {
    // T stands for "Type"
    private T t;
    public void set(T t) { this.t = t; }
    public T get() { return t; }
}

De cette façon, notre classe Box peut être réutilisée et nous pouvons remplacer T par n'importe quel type de notre choix :

Box<Integer> integerBox = new Box<Integer>();
Box<Double> doubleBox = new Box<Double>();
Box<String> stringBox = new Box<String>();

Méthodes génériques

Après avoir lu les classes génériques, examinons les méthodes génériques. Déclarer une méthode générique est très simple, il suffit d'ajouter un formulaire comme devant le type de retour :

public class Util {
    public static <K, V> boolean compare(Pair<K, V> p1, Pair<K, V> p2) {
        return p1.getKey().equals(p2.getKey()) &&
               p1.getValue().equals(p2.getValue());
    }
}
public class Pair<K, V> {
    private K key;
    private V value;
    public Pair(K key, V value) {
        this.key = key;
        this.value = value;
    }
    public void setKey(K key) { this.key = key; }
    public void setValue(V value) { this.value = value; }
    public K getKey()   { return key; }
    public V getValue() { return value; }
}

On peut appeler des méthodes génériques comme suit :

Pair<Integer, String> p1 = new Pair<>(1, "apple");
Pair<Integer, String> p2 = new Pair<>(2, "pear");
boolean same = Util.<Integer, String>compare(p1, p2);

Ou utilisez l'inférence de type dans Java1.7/1.8 pour laisser Java dériver automatiquement les paramètres de type correspondants :

Pair<Integer, String> p1 = new Pair<>(1, "apple");
Pair<Integer, String> p2 = new Pair<>(2, "pear");
boolean same = Util.compare(p1, p2);

Caractère limite

Nous voulons maintenant implémenter une telle fonction pour trouver le nombre d'éléments dans un tableau générique qui est supérieur à un élément spécifique. Nous pouvons l'implémenter comme ceci :

public static <T> int countGreaterThan(T[] anArray, T elem) {
    int count = 0;
    for (T e : anArray)
        if (e > elem)  // compiler error
            ++count;
    return count;
}

. Mais c'est évidemment faux, car à l'exception des types primitifs tels que short, int, double, long, float, byte, char, etc., d'autres classes peuvent ne pas être en mesure d'utiliser l'opérateur >, donc le compilateur signale une erreur, donc comment résoudre ce problème Drap de laine ? La réponse est d'utiliser des caractères de limite.

public interface Comparable<T> {
    public int compareTo(T o);
}

Faire une instruction similaire à la suivante équivaut à indiquer au compilateur que le paramètre de type T représente les classes qui implémentent l'interface Comparable, ce qui équivaut à indiquer au compilateur qu'elles implémentent toutes au moins la méthode compareTo.

public static <T extends Comparable<T>> int countGreaterThan(T[] anArray, T elem) {
    int count = 0;
    for (T e : anArray)
        if (e.compareTo(elem) > 0)
            ++count;
    return count;
}

Caractère générique

Avant de comprendre les caractères génériques, nous devons d'abord clarifier un concept. Empruntons la classe Box que nous avons définie ci-dessus. Supposons que nous ajoutions une méthode comme celle-ci :

public void boxTest(Box<Number> n) { /* ... */ }

. Alors, quels types de paramètres Box permet-il d'accepter maintenant ? Pouvons-nous transmettre Box ou Box ? La réponse est non. Bien que Integer et Double soient des sous-classes de Number, il n’existe aucune relation entre Box C’est très important. Approfondissons notre compréhension à travers un exemple complet.

​Nous définissons d’abord quelques classes simples, que nous utiliserons ci-dessous :

class Fruit {}
class Apple extends Fruit {}
class Orange extends Fruit {}

Dans l'exemple suivant, nous créons une classe générique Reader, puis dans f1() lorsque nous essayons Fruit f = fruitReader.readExact(apples); le compilateur signalera une erreur car il y a un écart entre List Apple> Cela n'a aucune relation.

public class GenericReading {
    static List<Apple> apples = Arrays.asList(new Apple());
    static List<Fruit> fruit = Arrays.asList(new Fruit());
    static class Reader<T> {
        T readExact(List<T> list) {
            return list.get(0);
        }
    }
    static void f1() {
        Reader<Fruit> fruitReader = new Reader<Fruit>();
        // Errors: List<Fruit> cannot be applied to List<Apple>.
        // Fruit f = fruitReader.readExact(apples);
    }
    public static void main(String[] args) {
        f1();
    }
}

Mais selon nos habitudes de pensée habituelles, il doit y avoir une connexion entre Apple et Fruit, mais le compilateur ne peut pas la reconnaître. Alors, comment résoudre ce problème en code générique ? Nous pouvons résoudre ce problème en utilisant des caractères génériques :

static class CovariantReader<T> {
    T readCovariant(List<? extends T> list) {
        return list.get(0);
    }
}
static void f2() {
    CovariantReader<Fruit> fruitReader = new CovariantReader<Fruit>();
    Fruit f = fruitReader.readCovariant(fruit);
    Fruit a = fruitReader.readCovariant(apples);
}
public static void main(String[] args) {
    f2();
}

Cela équivaut à dire au compilateur que les paramètres acceptés par la méthode readCovariant de fruitReader doivent uniquement être une sous-classe de Fruit (y compris Fruit lui-même), de sorte que la relation entre la sous-classe et la classe parent soit également liée.

Principe PECS

Ci-dessus, nous avons vu une utilisation similaire à , grâce à laquelle nous pouvons obtenir des éléments de la liste, pouvons-nous donc ajouter des éléments à la liste ? Essayons :

public class GenericsAndCovariance {
    public static void main(String[] args) {
        // Wildcards allow covariance:
        List<? extends Fruit> flist = new ArrayList<Apple>();
        // Compile Error: can&#39;t add any type of object:
        // flist.add(new Apple())
        // flist.add(new Orange())
        // flist.add(new Fruit())
        // flist.add(new Object())
        flist.add(null); // Legal but uninteresting
        // We Know that it returns at least Fruit:
        Fruit f = flist.get(0);
    }
}

La réponse est non, le compilateur Java ne nous permet pas de faire cela, pourquoi ? Autant considérer cette question du point de vue du compilateur. Parce que List lui-même peut avoir plusieurs significations :

List<? extends Fruit> flist = new ArrayList<Fruit>();
List<? extends Fruit> flist = new ArrayList<Apple>();
List<? extends Fruit> flist = new ArrayList<Orange>();

• Lorsque nous essayons d'ajouter une pomme, flist peut pointer vers new ArrayList();

• 
  

• Lorsque nous essayons d'ajouter un Orange, flist peut pointer vers new ArrayList();

• 
  

• Lorsque nous essayons d'ajouter un Fruit, le Fruit peut être n'importe quel type de Fruit, et flist peut vouloir uniquement un type spécifique de Fruit. Le compilateur ne peut pas le reconnaître et signalera une erreur.

Par conséquent, la classe de collection qui implémente

Que devons-nous faire si nous voulons ajouter des éléments ? Vous pouvez utiliser  :

public class GenericWriting {
    static List<Apple> apples = new ArrayList<Apple>();
    static List<Fruit> fruit = new ArrayList<Fruit>();
    static <T> void writeExact(List<T> list, T item) {
        list.add(item);
    }
    static void f1() {
        writeExact(apples, new Apple());
        writeExact(fruit, new Apple());
    }
    static <T> void writeWithWildcard(List<? super T> list, T item) {
        list.add(item)
    }
    static void f2() {
        writeWithWildcard(apples, new Apple());
        writeWithWildcard(fruit, new Apple());
    }
    public static void main(String[] args) {
        f1(); f2();
    }
}

　　这样我们可以往容器里面添加元素了，但是使用super的坏处是以后不能get容器里面的元素了，原因很简单，我们继续从编译器的角度考虑这个问题，对于List list，它可以有下面几种含义：

List<? super Apple> list = new ArrayList<Apple>();
List<? super Apple> list = new ArrayList<Fruit>();
List<? super Apple> list = new ArrayList<Object>();

　　当我们尝试通过list来get一个Apple的时候，可能会get得到一个Fruit，这个Fruit可以是Orange等其他类型的Fruit。

　　根据上面的例子，我们可以总结出一条规律，”Producer Extends, Consumer Super”：

• “Producer Extends” – 如果你需要一个只读List，用它来produce T，那么使用? extends T。

• 
  

• “Consumer Super” – 如果你需要一个只写List，用它来consume T，那么使用? super T。

• 
  

• 如果需要同时读取以及写入，那么我们就不能使用通配符了。

　　如何阅读过一些Java集合类的源码，可以发现通常我们会将两者结合起来一起用，比如像下面这样：

public class Collections {
    public static <T> void copy(List<? super T> dest, List<? extends T> src) {
        for (int i=0; i<src.size(); i++)
            dest.set(i, src.get(i));
    }
}

　类型擦除

　　Java泛型中最令人苦恼的地方或许就是类型擦除了，特别是对于有C++经验的程序员。类型擦除就是说Java泛型只能用于在编译期间的静态类型检查，然后编译器生成的代码会擦除相应的类型信息，这样到了运行期间实际上JVM根本就知道泛型所代表的具体类型。这样做的目的是因为Java泛型是1.5之后才被引入的，为了保持向下的兼容性，所以只能做类型擦除来兼容以前的非泛型代码。对于这一点，如果阅读Java集合框架的源码，可以发现有些类其实并不支持泛型。

　　说了这么多，那么泛型擦除到底是什么意思呢？我们先来看一下下面这个简单的例子：

public class Node<T> {
    private T data;
    private Node<T> next;
    public Node(T data, Node<T> next) }
        this.data = data;
        this.next = next;
    }
    public T getData() { return data; }
    // ...
}

　　编译器做完相应的类型检查之后，实际上到了运行期间上面这段代码实际上将转换成：

public class Node {
    private Object data;
    private Node next;
    public Node(Object data, Node next) {
        this.data = data;
        this.next = next;
    }
    public Object getData() { return data; }
    // ...
}

　　这意味着不管我们声明Node还是Node，到了运行期间，JVM统统视为Node