Recastage et héritage avec une List - Java - Programmation
Marsh Posté le 20-05-2008 à 12:56:05
juste un peu plus précisément, tu peux me donner la ligne de code stp ? C'est
Code :
|
qu'il faut que j'écrive, c'est ça ?
Je trouve ça pas terrible parce qu'on ne prends pas en compte que Tutu hérite de Toto avec cette méthode.
Marsh Posté le 22-05-2008 à 17:33:32
ok ça semble marcher mais j'aurais préféré jouer avec les types paramétrés qu'avec cette astuce douteuse...
Marsh Posté le 23-05-2008 à 09:35:59
ben les
Code :
|
et les
Code :
|
c'est fait pour ça normalement, mais j'ai pas réussit à m'en sortir avec...
Marsh Posté le 23-05-2008 à 16:18:45
En fait ça marche pas du tout.
Je reprends:
Code :
|
et:
Code :
|
dans la classe Toto j'ai un champs:
Code :
|
et son getter:
Code :
|
maintenant les choses se compliquent, dans la classe Tutu, j'ai:
Code :
|
et ça ne marche pas, il veut pas compiler.
J'ai essayé:
Code :
|
mais ça ne marche pas.
J'ai aussi essayé avec des
Code :
|
et
Code :
|
un peu partout, mais rien à faire.
Je perds énormément de temps avec ce problème, si quelqu'un pouvait m'expliquer ce qui ne va pas je lui en serais très reconnaissant.
Merci.
EDIT:
La meilleure solution que j'ai trouvée est la suivante:
Code :
|
Voilà ça a l'air de marcher, sauf que je me suis rendu compte d'un autre problème dans la méthode qui permet d'ajouter un élément dans la listeX de la classe mère Toto:
Code :
|
Marsh Posté le 24-05-2008 à 16:10:31
Peut-être que tu peux trouver ton bonheur la-dedans:
http://www.angelikalanger.com/Gene [...] csFAQ.html
Pour l'instant, je vois pas.
Au passage, le compilo d'eclipse considère que ces 2 méthodes sont identiques:
Code :
|
Ceci à cause du "type erasure" (le compilo Java transforme ces 2 signatures en List getList()).
Marsh Posté le 24-05-2008 à 17:05:29
En fait, tout bien réfléchi, je ne comprends pas l'utilité de ta méthode public List<Y> getListeX().
Déjà, le nom est trompeur, ce qui est mauvais signe. Ensuite, quitte à faire un cast, je pense qu'il est plus propre d'en laisser la responsabilité à l'appelant plutôt que de créer une liste supplémentaire et faire une grosse recopie sous le capot pour la retourner à l'appelant, là où on s'attendrait à ce qu'un getListe soit un simple retour d'un pointeur.
Marsh Posté le 26-05-2008 à 15:08:42
ben un Tutu contient une listeX puisque c'est avant tout un Toto, donc c'est normal qu'il ait sa méthode getListeX() mais il faut la redéfinir car comme c'est un Tutu c'est des X plus "particuliers" (des Y) que la liste contient.
Marsh Posté le 26-05-2008 à 15:47:32
"ça marche pas" n'aide pas bcp comme description de problème...
cimourdain a écrit : ben un Tutu contient une listeX puisque c'est avant tout un Toto, donc c'est normal qu'il ait sa méthode getListeX() mais il faut la redéfinir car comme c'est un Tutu c'est des X plus "particuliers" (des Y) que la liste contient. |
Par hasard, sais-tu que la relation List<Y> extends List<Y> ne sera en principe pas vérifiée si Y extends X ?
Marsh Posté le 26-05-2008 à 17:37:16
sircam a écrit : "ça marche pas" n'aide pas bcp comme description de problème... |
sircam a écrit : |
ça veut rien dire ce que tu dis.
Marsh Posté le 26-05-2008 à 17:53:52
M'enfin?
http://forum.hardware.fr/hfr/Progr [...] m#t1655359
Citation : Un moyen efficace d'exposer votre problème est le classique duo comportement attendu / comportement observé. Plus informatif que "ça ne marche pas" ou "j'ai une erreur". |
Pour ma remarque concernant l'héritage, si tu comprends pas, beh... essaye encore?
Marsh Posté le 20-05-2008 à 11:02:34
Bonjour à tous,
ne marche pas, normal, mais
ne marche pas non plus, alors comment faire ce recastage proprement ?
j'ai essayé
mais ensuite quand on fait
on est obligé de caster en faisant
Or je souhaite éviter ça en recastant "à la source" c'est à dire dans la méthode getTutuList()
Message édité par cimourdain le 23-05-2008 à 17:08:19