Discussion :

[win_ubuntu]

Salut,
c'est une question posé ICI.
voici ma solution:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
  public static <T extends Comparable< T>> T findMax(List<? extends T> list, int begin, int end) {
        ...
    }

la réponse à cette question dans le tutoriel était de cette forme:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
public static <T extends Object & Comparable<? super T>>
        T max(List<? extends T> list, int begin, int end) {
...
 
}

la question est la suivante:
pour quoi l'utilisation du type à paramètre T extends Comparable<? super T> et non seulement T extends Comparable< T>. quel est l'avantage.

[tchize_]

Le Comparable est souvent typé T extends Comparable<T> pour bien exprimer qu'il n'est comparable qu'à lui même. Cependant, historiquement, c'était compareTo(Object), donc beaucoup d'anciennes classes ont la signature Comparable<Object> qui est un parent de T avec ? super T on ratisse donc plus large dans les classes acceptées.
le T extends Object est totalement inutile, tout étend Object, inutile de le préciser.


Enfin, en java 8 on écrirait simplement:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
public static <T extends Comparable<? super T>> T findMax(List<? extends T> list, int begin, int end) {
    list.subList(begin,end).stream().max(Comparator::naturalOrder).get()
}

[adiGuba]

Salut,

Le Comparable est souvent typé T extends Comparable<T> pour bien exprimer qu'il n'est comparable qu'à lui même. Cependant, historiquement, c'était compareTo(Object), donc beaucoup d'anciennes classes ont la signature Comparable<Object> qui est un parent de T avec ? super T on ratisse donc plus large dans les classes acceptées.

Comparable<T> peut poser problème même avec des classes bien paramétrées... à partir du moment où l'héritage rentre en jeu.


Il n'est pas obligatoire pour une classe "XX" d'implémenter Comparable<XX>.
Et surtout en cas d'héritage où l'on pourrait hériter d'une implémentation de Comparable...


Donc en clair si l'on veut rester compatible avec la majorité des cas, il faut utiliser Comparable<? super T> à la place de Comparable<T>.


Exemple, avec ta méthode findMax() utilisant Comparable<? super T> on peut écrire le code suivant :
(sachant que Timestamp hérite de Date et est donc Comparable<Date>)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
	List<Date> dates = new ArrayList<>();
	List<Timestamp> timestamps = new ArrayList<>();
 
	Date maxDate = findMax(dates, 0, 10);
	Timestamp maxTimestamp = findMax(timestamps, 0, 10);

Mais si tu utilise Comparable<T> à la place de Comparable<? super T>, la dernière ligne de ce code génèrera une erreur inutilement...

a++

[win_ubuntu]

Mais si on utilise Comparable<T> à la place de Comparable<? super T>, la ligne suivante ne génère pas une erreur:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

	Date maxTimestamp = findMax(timestamps, 0, 10);

[adiGuba]

Mais si on utilise Comparable<T> à la place de Comparable<? super T>, la ligne suivante ne génère pas une erreur:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

	Date maxTimestamp = findMax(timestamps, 0, 10);

Car tu as changé le type de retour, et que T correspond désormais à "Date" au lieu de "Timestamp".
Cela fonctionne car il y a le <? extends T> sur la liste (pour les mêmes raisons), mais tu perds le type réel de l'objet en retour...


[edit]
Grosso modo pour un paramétrage avec T :

• <T> correspond obligatoirement au type T.
• <? super T> peut correspondre à T ou n'importe quel de ses types parents.
• <? extends T> peut correspondre à T ou n'importe quel se ses types enfants.

a++

[win_ubuntu]

Dans le même contexte, après le processus appelé Erasure :
Normalement on obtient le même code que ce soit pour Comparable<T> ou Comparable<? super T>.

voici le code après erasure:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
public static  Comparable  findMax(List<Comparable> list, int begin, int end) {
        ...
    }

donc les génerics sont ajoutés pour augmenter la puissance des compilateurs de détecter les erreurs à la compilation.

[tchize_]

Ce que tu viens de noter est à ne pas faire, ça désactive complètement le mécanisme de check du compilteur et va t'ammener des emmerdes :


Tu obtiens en retour un Comparable, de quelque chose, même plus une Date
On ne repère plus les incohérences dans la liste
Ca génère des warnings à tout va.

[win_ubuntu]

Ce que tu viens de noter est à ne pas faire, ça désactive complètement le mécanisme de check du compilteur et va t'ammener des emmerdes :


Tu obtiens en retour un Comparable, de quelque chose, même plus une Date
On ne repère plus les incohérences dans la liste
Ca génère des warnings à tout va.

Je ne pense pas que j'ai bien compris votre réponse. peut être que vous avez mal compris mon message.

[thelvin]

donc les génerics sont ajoutés pour augmenter la puissance des compilateurs de détecter les erreurs à la compilation.

Ouais c'est un but important, mais pas que ça. Ils s'occupent aussi de faire un cast de tes objets en fonction des génériques indiqués.

Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
List<String> desMots = new ArrayList<>();
desMots.add("Bonjour");
desMots.add("monde");
 
String premierMot = desMots.get(0);

L'équivalent sans générique, c'est :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
List desMots = new ArrayList();
desMots.add("Bonjour");
desMots.add("monde");
 
String premierMot = (String)desMots.get(0);

Avec un joli cast vers String.