Exercice sur les génériques pour développeur confirmé

Bonjour,

Je bute sur un exercice du livre Thinking in Java (jusqu'à présent je les enchainais tous :D).
J'ai pas envie de payer 20$ pour le corrigé de tous les exercices qui sont à télécharger sur le site du livre (surtout qu'ils sont pas disponibles pour la dernière édition), donc si quelqu'un a la solution, je suis preneur.
Voici donc l'énoncé (libre de droit) :

Create a generic class Generic1<T> with a single method that takes an argument of type T. Create a second generic class Generic2<T> with a single method that returns an argument of type T. Write a generic method with a contravariant argument of the first generic class that calls its method. Write a second generic method with a covariant argument of the second generic class that calls its method. Test using the typeinfo.pets library.

La libraire typeinfo.pets contient une hiérarchie de classes avec Pet comme super classe et des classes enfants comme Cat, Dog, etc.

Alors les pros ?

Bonjour,

Elle est où la question ?

Je cherche la solution à l'exercice. Je n'ai pas vraiment de question précise dessus car je ne suis pas sur d'avoir bien compris l'énoncé. Toute piste est la bienvenue.

Bon juste une piste alors, comme ça a vue de nez comme ça parle de contravariant et de covariant, c'est certainement pour te faire utiliser des wildcards avec les mots clés extends et super.
Comme ça tu passes d'un type à l'autre.

Bon courage, mais bon les exercices des bouquins c'est un peu bof, en pratique il vaut mieux simplifier que de s'amuser a ce genre de manip.

Je suis bien d'accord qu'en pratique il faut simplifier.
Voilà ce que j'avais commencé à écrire :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

class Generic1<T> {   public void meth(T t) { }   }   class Generic2<T> {   public T meth(T t) { return t; }   public void meth1(Generic1<? super Pet> u) { u.meth(new Cat()); }   public void meth2(Generic2<? extends Pet> v) { // Je vois pas comment appeler v.meth() ici .. }   }   class Pet { }   class Cat extends Pet { }

---

Salut,


La méthode de la seconde classe se contente de retourner un élément de type T sans paramètre, donc il suffit de faire ceci :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

class Generic2<T> {   public T meth() { return t; }   public void meth2(Generic2<? extends Pet> v) { Pet pet = v.meth(); }   }

---

Mais bon perso je ne trouve pas cela très clair présenté comme cela.

En général je préfère utiliser les collections pour parler de cela...



a++

Citation:

---

Envoyé par adiGuba

Salut,

Code:

---

1 2 3 4 5 6 7 8 9 10 11

class Generic2<T> {   public T meth() { return t; }   public void meth2(Generic2<? extends Pet> v) { Pet pet = v.meth(); }   }

---

---

Comment instancier un objet t du type générique T dans :

Code:

---

1 2 3

public T meth() { return t; }

---

?

Citation:

---

Envoyé par Tesing

Comment instancier un objet t du type générique T dans :

---

Tu ne peux pas (mais je ne pense pas que l'intérêt de la question soit là).

Disons que ta classe Generic2 pourrait être défini comme cela :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

class Generic2<T> { private final T t;   public Generic2(T t) { this.t = t; }   public T meth() { return t; } }

---

Mais comme je l'ai dit je préfère utilise les collections pour décrire l'utilisation de la contravariance/covariance. Si j'ai le temps j'essayerais de faire un topo rapide là dessus...


a++

Ok, merci pour ta réponse.
Effectivement, je suis un peu déçu du chapitre sur les génériques de ce bouquin. Pour autant, les autres sont très complets.

Citation:

---

Envoyé par Tesing

Write a generic method with a contravariant argument of the first generic class that calls its method. Write a second generic method with a covariant argument of the second generic class that calls its method. Test using the typeinfo.pets library.

---

Vu que ce sont les méthodes, qui doivent être génériques, j'ai l'impression que ce serait plutôt ça :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

public class TestGeneric1And2 {   public static <T> void testGen1(Generic1<? super T> gen1, T t) { System.out.println("Called testGen1"); gen1.method(t); }   public static <T> T testGen2(Generic2<? extends T> gen2) { System.out.println("Called testGen2"); return gen2.method(); }   public static void main(String[] args) { Generic1<Pet> gen1 = new Generic1<Pet>(); testGen1(gen1, new Dog());   Generic2<Cat> gen2 = new Generic2<Cat>(new Cat()); Pet pet = gen2.method(); pet.doSomething(); }   }

---

Ce qui se voit mieux avec les collections :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

public static <T> void insertInMiddle(List<? super T> list, T item) { list.add(list.size()/2, item); }   public static <T> T getMiddleElement(List<? extends T> list) { return list.get(list.size()/2); }   public static void main(String[] args) { List<Pet> pets = new ArrayList<Pet>(); pets.add(new Dog()); pets.add(new Cat()); pets.add(new Rat());   System.out.println(pets); insertInMiddle(pets, new Bird()); System.out.println(pets);   List<Dog> dogs = new ArrayList<Dog>(); dogs.add(new Dog()); dogs.add(new Dog()); dogs.add(new Dog());   System.out.println(dogs); Pet pet = getMiddleElement(dogs); System.out.println(pet); }

---

Ok, merci, effectivement, ça me paraît juste.

Citation:

---

Envoyé par adiGuba

Mais comme je l'ai dit je préfère utilise les collections pour décrire l'utilisation de la contravariance/covariance. Si j'ai le temps j'essayerais de faire un topo rapide là dessus...

---

Je m'y met... Attention ca risque d'être assez long...




On reprendra donc la classe Pet avec ses sous-classes :

Code:

---

1 2 3 4 5 6

class Pet { public String getName(); }   class Cat extends Pet {} class Dog extends Pet {}

---

Notre application va manipuler les listes d'animaux, et donc on va avoir besoin de quelques utilitaires.

• La première consistera simplement à afficher le nom de chaque animal.
• La seconde permettra d'ajouter un chien dans une liste.

A première vue, on pourrait se contenter de ceci :

Code:

---

1 2 3 4 5 6 7 8 9

public static void print(List<Pet> list) { for (Pet pet : list) { System.out.println( pet.getName() ); } }   public static void addDog(List<Pet> list, Dog aDog) { list.add( aDog ); }

---

Maintenant, dans notre application on est amené à utiliser plusieurs types de listes.
Il n'y a aucun soucis avec les List<Pet>, mais il est impossible d'utiliser une List<Dog> avec nos méthodes, car les types ne sont pas compatible !!!

En effet ce n'est pas la même chose. Une List<Dog> ne peut contenir que des Dog (ou type enfants), alors qu'une List<Pet> peut contenir aussi des Cat, Pet ou tout autre classe fille de Pet...

Du coup le compilateur interdit toute tentative de conversion de ce style :

Code:

---

1 2 3 4

List<Dog> dogs = ... List<Pet> pets = (List<Pet>) dogs; // ERREUR DE COMPILATION   pets.add( new Cat() ); // ????

---

Sinon on pourrait se retrouver dans des cas incohérent, par exemple où on ajouterais un Cat dans une liste de Dog...


Mais du coup le code est moins générique, dans le sens où il faudrait faire une méthode print() pour chaque type de liste...

La covariance/contravariance vient pallier à cela, en diminuant un peu le typeage.







La covariance permet de définir partiellement le type. Ainsi List<? extends Pet> représente toutes les listes paramétrées avec la classe Pet ou un type enfant, et est donc compatible avec :

Code:

---

1 2	List<Dog> dogs = ... List<? extends Pet> pets = dogs; // OK

---

Par contre, comme on ne connait pas le type précis du paramétrage Generics T, on ne peut pas utiliser les méthodes qui utilisent ce paramétrage en paramètre (comme add(T) par exemple). En effet puisqu'on ne connait pas le type précis à utiliser, on ne peut pas appeler la méthode :

Code:

---

1 2 3

List<? extends Pet> pets = ...   pets.add( new Dog() ); // ERREUR DE COMPILATION

---

Dans ce cas précis, rien ne permet d'afficher que la liste peut accepter des Dog (ce pourrait tout à fait être une List<Cat> après tout).


Par contre, il n'y a aucun problème à utiliser les méthodes qui retourne ce type paramétré T. En effet, bien que l'on ne connaisse pas le type précis, on sait qu'il s'agit au moins d'un Pet. Qu'on ait affaire à une List<Pet>, List<Cat>, List<Dog> ou de toute autre List<classe-fille-de-Pet>, on sait que ce sera forcément un Pet.

Du coup notre méthode print() pourra être changer comme ceci :

Code:

---

1 2 3 4 5

public static void print(List<? extends Pet> list) { for (Pet pet : list) { // utilise iterator() qui retourne Iterator<T> System.out.println( pet.getName() ); } }

---

:arrow: Désormais notre méthode est utilisable avec des List<Pet>, List<Cat>, List<Dog>... simplement en changeant sa signature.







La contravariance, c'est exactement l'inverse.
Ainsi List<? super Dog> correspond à une liste paramétré avec Dog ou un type parent (donc Pet ou Object dans ce cas précis).
Du coup on peut très bien utiliser les méthodes qui utilisent le type paramétré en paramètre :

Code:

---

1 2 3

List<? super Dog> dogs = ...   dogs.add( new Dog() ); // OK

---

En effet, on est sûr que le paramétrage correspond à un type parent, donc on peut très bien lui passer une valeur correcte.

Du coup, notre method addDog() pourrait s'écrire comme ceci :

Code:

---

1 2 3

public static void addDog(List<? super Dog> list, Dog aDog) { list.add( aDog ); }

---

:arrow: Désormais notre méthode est utilisable avec des List<Dog>, List<Pet> ou List<Object>... bref toutes les listes pouvant contenir un Dog !


Comme la covariance, la contravariance nous limite sur certaine méthode. Ainsi comme on ne connait pas le type précis, on ne peut pas utiliser les méthodes retournant un objet paramétré avec T, puisqu'on ignore son type.
Enfin plus précisément dans ce cas là on peut appeler la méthode, mais sa valeur de retour ne sera pas typé du tout :
[code]

Code:

---

1 2 3 4

List<? extends Dog> dogs = ...   dogs.add( new Dog() ); // OK Object o = dogs.get(0); // OK, mais pas typé

---

Bref : les Generics imposent un typeage stricte, que les notions de covariance/contravariance permettent d'atténuer (avec quelques limitations).



a++

impeccable, c'est très clair :ccool:

Citation:

---

Envoyé par adiGuba

...

---

Super post, ça mériterait bien un billet ou un mini article :ccool:.

Par contre je pense que tu as pas fait une erreur de frappe/copier/coller dans la partie contravariance où dans le code il y a extends et pas super.

Citation:

---

Envoyé par adiGuba

La contravariance, c'est exactement l'inverse.
Ainsi List<? super Dog> correspond à une liste paramétré avec Dog ou un type parent (donc Pet ou Object dans ce cas précis).
Du coup on peut très bien utiliser les méthodes qui utilisent le type paramétré en paramètre :

Code:

---

1 2 3

List<? extends Dog> dogs = ... dogs.add( new Dog() ); // OK

---

En effet, on est sûr que le paramétrage correspond à un type parent, donc on peut très bien lui passer une valeur correcte.

Du coup, notre method addDog() pourrait s'écrire comme ceci :

Code:

---

1 2 3

public static void addDog(List<? extends Dog> list, Dog aDog) { list.add( aDog ); }

---

:arrow: Désormais notre méthode est utilisable avec des List<Dog>, List<Pet> ou List<Object>... bref toutes les listes pouvant contenir un Dog !

---

Citation:

---

Envoyé par le y@m's

Super post, ça mériterait bien un billet ou un mini article :ccool:.

---

J'essayerais de faire un truc plus concret un jour... mais je suis sur un autre article en ce moment ;)

Citation:

---

Envoyé par le y@m's

Par contre je pense que tu as pas fait une erreur de frappe/copier/coller dans la partie contravariance où dans le code il y a extends et pas super.

---

Oui bien vu !
Je corrige cela vite fait :D


a++

La conclusion de l'article est-elle que le code suivant fonctionne?

Code:

---

1 2 3 4 5 6 7 8

List<Dog> dogs = ... addPet(dogs, new Dog()); printPet(dogs);   List<Cat> cats = ... addPet(cats, new Cat()); printPet(cats);

---

Pour le print() oui... mais pas pour le add() puisque les types sont incompatibles :

Code:

---

1 2 3

public static void addDog(List<? super Dog> list, Dog aDog) { list.add( aDog ); }

---

Mais il est vrai qu'on pourrait vouloir aller plus loin sur cet exemple, même si on sort un peu de la covariance/contravariance...

La différence c'est qu'ici on a un paramètre en plus, dont le type doit correspond au type max du paramètrage.
Tel quel il faudrait dupliquer les méthodes, afin de garder cette correspondance entre le paramétrage de la list et le paramètre qu'on va lui ajouter :

Code:

---

1 2 3 4 5 6 7 8 9

public static void addPet(List<? super Pet> list, Pet aPet) { list.add( aPet ); } public static void addCat(List<? super Cat> list, Cat aCat) { list.add( aCat ); } public static void addDog(List<? super Dog> list, Dog aDog) { list.add( aDog ); }

---

Pour cela, il faut paramétré la méthode avec les Generics (indépendamment de la classe dans laquellle elle se trouve).
Cela se fait assez simplement en précédant le type de retour par un paramétrage Generics :

Code:

---

1 2 3

public static <P> void addPet(List<? super Pet> list, Pet aPet) { list.add( aPet ); }

---

Pour l'instant ce paramétrage est complètement inutile puisqu'on ne l'utilise pas.
Mais il va nous permettre de lier le type paramétré de la List au type du second paramètre :

Code:

---

1 2 3

public static <P> void addPet(List<? super P> list, P aPet) { list.add( aPet ); }

---

Et notre méthode peut être utilisé avec n'importe quelle combinaison, à condition que cela soit cohérent bien sûr :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

List<Pet> pets = ... addPet(pets, new Pet()); // OK addPet(pets, new Dog()); // OK addPet(pets, new Cat()); // OK   List<Cat> cats = ... addPet(cats, new Pet()); // ERREUR addPet(cats, new Dog()); // ERREUR addPet(cats, new Cat()); // OK   List<Dog> dogs = ... addPet(dogs, new Pet()); // ERREUR addPet(dogs, new Dog()); // OK addPet(dogs, new Cat()); // ERREUR

---

Seul bemol : à l'intérieur de notre methode, le paramètre 'aPet' est vue comme un Object.
On fait la méthode est tellement générique qu'on pourrait l'utiliser pour ajouter n'importe quoi dans n'importe quelle liste :

Code:

---

1 2	List<Date> dates = ... addPet(dates, new Date());

---

Selon les cas ce comportement peut être souhaitable, mais pas forcément.
Par exemple si on veut utiliser des méthodes de "Pet".

Dans ce cas là il faut modifier le type de "P" via un wildcard. Par exemple pour que ce soit obligatoirement un Pet (ou fils) il suffit d'utilier <P extends Pet> à la place de <P> :

Code:

---

1 2 3 4 5

public static <P extends Pet> void addPet(List<? super P> list, P aPet) { // aPet est de type Pet, donc on peut utiliser ses méthodes : System.out.println(" adding " + aPet.getName() ); list.add( aPet ); }

---

Désormais, notre méthode est limité au cas d'utilisation où le type P correspond à un Pet (ou classes fils) ;)

Attention : cela ressemble à la variance/covariance mais ce n'est pas tout à fait la même chose.
Par exemple on ne peut pas utiliser <P super Pet> dans le paramétrage d'une classe/méthode, car cela n'a pas de sens...

Reste le problème du nommage du type Generics "P"... Par convention on doit utiliser une lettre en majuscule, mais ce n'est pas super lisible lorsqu'on en manipule beaucoup :(



a++

Je suis partant pour synthétiser les réponses et écrire un article didactique sur le sujet.