contrainte extends sur générique

Hello !!
Voilà , j'ai une petite question .... je sais , encore une !! :aie:

donc voilà je suis dans une classe qui n'est pas générique, mais prend en comptes des paramètres génériques dans son constructeur que je restitue via des getters ... j’espère que c'est pas une erreur de conception ??

voilà à quoi ça ressemble

Code:

---

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

class test{   protected List<? extends TreeNode> sourceNodes; protected Class<? extends TreeNode> creationClass;   public <T extends TreeNode, U extends TreeNode> test( List<T> sourceNodes, Class<U> clazz){ this.sourceNodes = sourceNodes; this.creationClass = clazz; } }

---

j'ai pensé que c'était possible de modifier la signature de mon constructeur comme ca

Code:

---

1 2 3

public <T, U extends TreeNode> test( List<T> sourceNodes, Class<U> clazz);

---

Mais mon ide me signale une érreur

Citation:

---

incompatible types
required: java.util.List<? extends jocode.tree.model.TreeNode>
found: java.util.List<T>

---

Je comprends pas pourquoi ....avec cette syntaxe réduite c'est comme si T et U était en faite le même template ...

C'est pas tros génant , je peux toujours utiliser la première version, mais j'aime bien tout savoir :zoubi:
Si quelqu’un a deux minutes pour m'expliquer ou me donner un lien ...

Sinon j'ai une autre question , là aussi sur les génériques.

J'ai une méthode comme ça

Code:

---

1 2	public <T extends TreeNode> List<T> getSelectionNodes();

---

et la même qui ne retourne qu'un noeud

Code:

---

1 2	public <T extends TreeNode> T getSelectionNode();

---

Je sais pas si je fait bien d'inclure des paramètres générique dans la seconde méthode. En effet elle ne fait que caster dynamiquement son résultat au type déclaré de la variable affecté par son invocation.
De plus , un cast reste nécessaire par exemple pour le passage de paramètres à une méthode , ect ....(ou un truc bizarre obj.<TreeNode>getSelectionNode())
J'ai pas mal de getters, et si j'applique la généricité au paramêtre qui ne sont pas des collections, je suis dans le :scarymov:
Pourtant ça semblerais plus logique de faire ainsi puisse que les retours de mes collections sont générique, ce qui reste super pratique ....
Donc dilème :ouin::ouin:
Avez des conseils quand à l'utilisation des génériques?? Dois-je me passer de renvoyer des résultats génériques ??

merci

Citation:

---

Envoyé par kimjoa

Je comprends pas pourquoi ....avec cette syntaxe réduite c'est comme si T et U était en faite le même template ...

---

... Supposons que tu veuilles avoir deux paramètre T et U, en n'imposant aucune contrainte sur T et en imposant que U étende TreeNode.
Ça ressemblerait à quoi ? Écris-le. Compare avec ta "syntaxe réduite."

Cette remarque sur la syntaxe étant faite, est-ce que ce n'est pas plus simple de faire ton constructeur ainsi :

Code:

---

public Test(List<? extends TreeNode>, List<? extends TreeNode>) {

---

?

Citation:

---

Je sais pas si je fait bien d'inclure des paramètres générique dans la seconde méthode. En effet elle ne fait que caster dynamiquement son résultat au type déclaré de la variable affecté par son invocation.

---

La première fait encore moins que ça, elle rassure le compilateur en lui disant que la liste renvoyée est une liste du type attendu, sans jamais s'en assurer. Ce qui provoquera tôt ou tard des ClassCastException, à un endroit moins attendu que là où ça devrait.
Sauf si la liste est vide, mais j'imagine que ce n'est pas le but.

Citation:

---

J'ai pas mal de getters, et si j'applique la généricité au paramêtre qui ne sont pas des collections, je suis dans le :scarymov:
Pourtant ça semblerais plus logique de faire ainsi puisse que les retours de mes collections sont générique, ce qui reste super pratique ....

---

C'est ta classe, pas tes méthodes, qu'il faut paramétrer, voyons ! Les paramètres de méthodes se perdent d'un appel de méthode à l'autre. Ce qu'il te faut, c'est lier le paramètre à une instance de la classe, pour qu'il soit retenu pour tous les appels de méthodes. Et ça c'est un paramètre de classe.

Je crois que ce que tu cherche à faire, c'est plutot

Code:

---

1 2 3 4 5 6 7 8 9 10

class test<T extends TreeNode>{   protected List<T> sourceNodes; protected Class<T> creationClass;   public test(List<T> sourceNodes, Class<T> clazz){ this.sourceNodes = sourceNodes; this.creationClass = clazz; } }

---

ça c'est pour le général. Pour ton erreur en pratique (dans ton code donc), tu définis ton membre sourceNode comme étant un List<? extends TreeNode> mais tu tente de lui assigné la valeur passée en paramêtre qui est une List<?>, donc pas nécessairement étendant TreeNode.

merci les gars pour vos réponses :ccool:

thelvin

Citation:

---

Supposons que tu veuilles avoir deux paramètre T et U, en n'imposant aucune contrainte sur T et en imposant que U étende TreeNode.

---

Ba ouais , carrement :) ... encore une question à deux franc six sous ...je les accumule en ce moment :ouin::ouin:

Sinon tchize_, ton code marche très bien , d’ailleurs le tien aussi thelvin
Du coup je sais pas si dois faire une classe générique , ou juste des constructeurs acceptant des génériques...
Avez vous un conseil sur quand utiliser l'une des deux possibilité?

Sinon pour mon autre remarque, je vais me limiter à l'emploie de générique via des getters , juste qu'au collections .... d'ailleurs me semble que les génériques on d'abord été prévue pour les collections ....

En tout cas merci d'avoir pris le temps de me répondre !! a++

les collections ont été les classes les plus refactorées avec les generics, mais ils ne le sont pas dédiés. On met les generics sur la classes si ils ont une influence sur le comportement de cette classes (exemple, définissent un stockage interne). On les met sur les méthodes quand ils n'ont d'usage que pour la durée d'exécution de la méthode. Exemple de Generic sur la classe:

Code:

---

1 2	List<MonType> type = ...; MonType t = type.get(0);

---

exemple sur la méthode, avec spring

Code:

---

1 2	ApplicationContext ctx = ........; MonType t = ctx.getBean(MonType.class);

---

Donc dans mon exemple le mieux été de faire une classe générique étant donné que je stock les paramètres générique du constructeur ...

merci pour ce complément d'information tchize_ c'est cool
bye !