Discussion :

[wafiwafi]

Bonjour,
Pour une question de polymorphisme, List est une interface.
Toutes ses méthodes sont implémentées par des sous classes des différentes hiérarchies....
Quelqu'un peut me citer un exemple de polymorphisme permettant aux différents utilisateurs de bien comprendre l'hiérarchie des collections proposée par java et surtout le pourquoi de la présence des classes abstraites et des interfaces....dans ce cas précis.

Merci à vous

[chaplin]

http://fmora.developpez.com/tutoriel.../introduction/
http://download.oracle.com/javase/tu...ns/interfaces/

[wafiwafi]

Merci pour ta réponse chaplin.
Oui, je connais bien le cours. Je vais m'expliquer davantage.
Dans le code suivant que j'utilise machinalement :

Code :

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

1
2
3
4
5
6
7
8
List maListe=new LinkedList() ; // on crée notre liste chaînée
maListe.add(new Integer(1)) ; // on ajoute l'entier 1 à la liste
maListe.add(new Float(2.15)) ; // on ajoute le flottant 2.15 à la liste
/* On remarque ici que l'entier 1 est la tête de la liste, et que le flottant
 * est la queue de la liste. */
Integer monEntier=(Integer)maListe.getFirst() ; // on n'oublie pas de faire le cast
Float monFloat=(Float)maListe.getLast(); // on n'oublie pas de faire le cast
maListe.remove(0) ; // on retire l'entier , le flottant devient la tete

Une question qui a été posée :
Pourquoi référencer maListe par List et non LinkedList?
Ma réponse : Polymorphisme!!!
Réplique:
Un exemple?
C'est l'objectif de ma demande.
Personnellement, je pourrais avancer que dans un code , on pourrait avoir besoin de choisir une structure de données de façon polymorphe.
J'ai traité ce cas cela fait un petit moment. J'aimerais avoir un exemple simple!
Cordialement

[wafiwafi]

Merci thelvin, C'est bien ce que je cherchais. Quelque chose de limpide.
C'est parfait comme exemple.

[adiGuba]

Salut,


Les interfaces sont surtout utile lorsque tu définis une API qui sera utilisée par d'autres développeurs. En effet si tu imposes une implémentation spécifique tu va fortement limité l'utilisation de ta méthode, en obligeant les développeurs à faire des conversions inutiles.

Par exemple si une méthode attend une liste d'email. Basiquement on pourrait utiliser une ArrayList :

Code :

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

	public void method(ArrayList<String> emails) {

C'est bien mais pourquoi obliger les développeurs à utiliser une ArrayList ? A moins que l'implémentation de ta méthode requiert réellement une ArrayList cela n'a aucun intérêt !

Autant utiliser une List :

Code :

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

	public void method(List<String> emails) {

Tu n'as pas modifié ton code, mais ta méthode est maintenant directement utilisable avec toute sorte de List.

Mieux : si tu n'as pas besoin de la notion d'ordre de la List, tu peux directement utiliser une Collection :

Code :

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

	public void method(Collection<String> emails) {

Désormais tu peux utiliser toute sorte de List ou de Set, ou n'importe quels autres implémentations de Collection...

Et, pour aller encore plus loin, si tu te contentes de parcourir la collection via un Iterator (ou la boucle for-each), tu peux même utiliser Iterable :

Code :

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

	public void method(Iterable<String> emails) {

Bref en choisissant correctement le type tu simplifies fortement l'utilisation de ton API en élargissant les possibilités...


a++

[wafiwafi]

C'est également un bon exemple convainquant!
J'ai une petite question par rapport au raisonnement:

Tu n'as pas modifié ton code, mais ta méthode est maintenant directement utilisable avec toute sorte de List.

Les méthodes dans List sont vides. On ne propose qu'une enveloppe pour jouir du polymorphisme.
Tu veux dire qu'une application peut raisonner sur List et peu importe d’où viennent les données...
Merci à toi

[adiGuba]

Tu veux dire qu'une application peut raisonner sur List et peu importe d’où viennent les données...

Oui c'est exactement le principe. Dans l'exemple j'ai besoin d'une "liste" d'emails. Et par "liste" je veux dire une liste au sens large, sans notion de trie, d'unicité ou autres...

Dans ce cas j'utilise l'interface la plus "simple" selon mes besoins. Je me fiche de l'implémentation qui sera utilisé, tant qu'elle respectent le contrat de l'interface.

Prenons un code basique comme celui-ci qui se contentent d'afficher tous les emails :

Code :

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

1
2
3
4
5
	public void method(Iterable<String> emails) {
		for (String email : emails) {
			System.out.println(email);
		}
	}

Du moment que cela me renvoi un Iterator valide pour le for-each, je me fichent complètement de savoir si le paramètre sera une ArrayList, une LinkedList, un Vector, un HashSet, un TreeSet, un ArrayBlockingQueue ou n'importe quelles autres implémentations...

Ici je n'ai aucune raison d'imposer un type spécifique... donc autant rester le plus large possible


a++

[thelvin]

- Existence de ArrayList et LinkedList :

Les deux implémentations ont leurs propres avantages et inconvénients, qui sont mutuellement exclusifs. Parfois on a besoin de l'une et parfois de l'autre. C'est pour ça qu'elles existent toutes les deux.

- Intérêt d'avoir une interface List, implémentée par ArrayList et LinkedList.

Quand on fait un programme pour une List, comme par exemple remplacer les String qui contiennent le mot "fou" par le mot "malade", on se tape complètement de savoir si on a affaire à une ArrayList, une LinkedList, une Arrays.asList() ou quoi que ce soit d'autre.
C'est toujours le même programme. Ce programme agit sur les List. Peu importe leur implémentation interne. C'est à ça que sert une interface, respectée par toutes les implémentations.

- Intérêt d'avoir Collection, étendue par List et Set

D'ailleurs c'est la même chose pour les programmes s'appliquant à n'importe quelle Collection, que ce soit List, Set ou autre chose. Par exemple, compter le nombre de String de la collection qui ont plus de 7 caractères.
On s'en fout de savoir si c'est un Set, une List ou que sais-je, on veut juste compter ses putains d'éléments. Le programme est le même dans tous les cas. D'où l'intérêt d'une interface Collection étendue ou implémentée par tout ce qui est une Collection.

- Intérêt d'AbstractList, étendue par LinkedList et ArrayList.

Même si LinkedList et ArrayList fonctionnent de manière très différentes, il y a aussi beaucoup de méthodes qu'elles implémentent exactement pareil :

-- isEmpty() c'est rien d'autre que size() == 0
-- add(Element e) c'est juste add(size(), e)
-- toString(), toArray(), equals(), hashCode(), tous ces trucs-là consistent juste à parcourir la List et se foutent complètement de savoir comment elle est implémentée en interne.

Toutes ces méthodes sont donc programmées pareil, ou en tout cas devraient l'être, pour la plupart des List. Mais List est une interface, elle ne contient aucune implémentation.
D'où l'intérêt de AbstractList, qui contient le code commun ou utile à toute implémentation de List, et donc étendue par ArrayList et LinkedList. D'autres implémenteurs de List peuvent s'en servir... Mais si ça ne leur convient pas ils n'y sont pas obligés.