archangel a écrit :
Imaginons que ton truc marche , et que l'on est ça : Code :
- public interface IA { /*...*/ }
- public class A implements IA { /*...*/ }
- public class B implements IA { /*...*/ }
| j'utilise ta méthode m1() pour récupérer la collection, mais moi je ne sais pas comment tu l'as codé, j'utilise ta librairie en gros, et donc je fais :
Code :
- B b = new B();
- Collection<IA> maCollection = toto.m1();
- maCollection.add(B);
|
Et là je me demande ce qui se passerait sachant que toi tu m'as envoyé une ArrayList<A>
|
Je pensais que maCollection serait considérée une Collection<IA>, meme j'y ai envoyé un ArrayList<A>.
J'imaginais que ça aurait un comportement similaire à
Code :
- B b = new B();
- Collection<IA> maCollection = new ArrayList<IA>();
- for (IA a : toto.m1()) {
- maCollection.add(a);
- }
- maCollection.add(b);
|
avec à l'interieur de cette Collection des objets (A ou B) sur lesquels sont applicables les methodes de IA.
Mais si en réalité, ce que renvoie m1() (en admettant qu'elle soit correcte) est implementé quoiqu'il en soit comme un ArrayList<A>, je veux bien admettre qu'on ne puisse pas y mettre autre chose que du A.
Taz a écrit :
Une collection de A n'est pas une collection de IA. Après, les generics java et leur bridge, ça fait du gros n'importe quoi, tu peux y coller ce que tu veux dedans, ça dira rien mais quand tu récupèreras, là tu te prendras du cast exception.
|
Si A "est un" IA, je ne vois pas pourquoi un ensemble de A ne pourrait pas être un ensemble de IA. Moi au final je m'en fous de ce qu'il y a dans la collection, du moment ou ça implémente IA (et donc que je peux y appliquer ses méthodes). Je veux bien comprendre que d'un point de vue technique ça pose quelques problemes, mais d'un point de vue purement conceptuel, je trouve que c'est un peu gênant qu'on ne puisse pas le faire.
Je pense que j'ai saisi le fond du probleme, merci pour vos réponses.