Mettre une valeur dans un Set<? extends String>

Bonjour,

Tout le problème est dans le titre:

Code:

---

1 2 3

Set<? extends String> s; s.add("a");

---

Provoque un message d'erreur pas très simple à comprendre.

J'ai quand même réussi à ajouter un élément dans s:

Code:

---

1 2	s.add(null);

---

mais ce n'est pas très util.

Ma question est donc: est-il possible de mettre des valeurs dans mon ensemble s? Si oui, comment? Sinon, un 'Set<? extends String>' n'est-il qu'un jouet théorique ou a-t-il une utilité?

Remarquons que l'on peut supprimer des éléments de s car la méthode remove attend un Object en paramètre.

Merci de vos réponses.

Bonjour,

Citation:

---

Envoyé par LGnord

Provoque un message d'erreur pas très simple à comprendre.
.

---

Lequel ?

Sinon la classe String étant final, elle ne peut être étendue, je ne vois donc pas l'intérêt de <? extends String>, un <String> suffira :)

@+

afrikha, merci pour ta réponse.

Le message d'erreur est le suivant:

Code:

---

1 2	The method add(capture-of ? extends String) in the type Set<capture-of ? extends String> is not applicable for the arguments (String)

---

C'est donc un problème de typage.

La remarque sur le type String est trés pertinente mais elle ne m'aide pas. En effet, j'ai pris cet exemple pour poster mais j'ai le problème avec un type qui n'est pas final.

Code:

---

1 2 3 4 5

class A{}   java.util.Set<? extends A > s; s.add(new A());

---

Et le message d'erreur:
The method add(capture-of ? extends A) in the type Set<capture-of ? extends A> is not applicable for the arguments (A)

Salut,

Citation:

---

Envoyé par LGnord

Et le message d'erreur:
The method add(capture-of ? extends A) in the type Set<capture-of ? extends A> is not applicable for the arguments (A)

---

C'est tout à fait normal : tu ne connais pas le type exact des éléments de ton Set. Tu sais juste qu'il s'agit d'objet héritant de A (ou A lui-même).

La notation ? extends permet donc une espèce d'accès en lecture seulement : tu ne connais pas le type réel, mais tu connais un de ses types "parents". Ainsi tu peux lire les élements du Set (il seront forcément du type de A) mais tu ne peux pas y ajouter des éléments car tu ne connais pas le type précis des éléments du Set.


Imagine que tu ais une classe fille B qui hérite de A, tu écrires ceci :

Code:

---

java.util.Set<? extends A > s = new HashSet<B>();

---

Si le compilateur te laissait ajouter un élement de type A :

Code:

---

s.add(new A());

---

:arrow: Tu te retrouverais dans un état incohérent puisque tu ajoutes un objet de type A dans un Set<B> ce qui ne doit pas être possible !




La question a se poser est plutôt : Pourquoi utiliser ? extends A et que cherches-tu a faire avec cela ?


a++

Merci adiGuba, ton explication est très claire.

Citation:

---

Tu te retrouverais dans un état incohérent puisque tu ajoutes un objet de type A dans un Set<B> ce qui ne doit pas être possible !

---

A la différence des tableaux qui ont une gestion à run-time (ArrayStoreException), c'est la compilation qui nous interdit de mélanger des A et des B dans un ensemble.

Citation:

---

La notation ? extends permet donc une espèce d'accès en lecture seulement.

---

Je peux donc lire dans mon ensemble mais pas y écrire. Il m'est donc complétement inutil.

Citation:

---

Pourquoi utiliser '? extends A'?

---

Je vais voir si je peux m'en passer.
Mais il doit quand même exister des cas où utiliser un type paramètré par '? extends A' est util?

Bonjour,

Citation:

---

Envoyé par LGnord

Mais il doit quand même exister des cas où utiliser un type paramètré par '? extends A' est util?

---

Yep, pour pouvoir lui affecter une Liste de B avec B étend A.
Si tu déclares ta liste comme List<A>, lui affecter un ArrayList<B> te donnerait une erreur de compile car même si B étend A, List<B> n'a aucun lien avec List<A>.

Tu utilise ce genre de déclarations quand:
- Il s'agit de lecture seule.
- Tu veux donner plus de flexibilité à l'utilisateur quand il doit te fournir une liste.

Pour pouvoir écrire dans une liste de ce type, il faut plutôt passer par <? super A>.

Citation:

---

Envoyé par LGnord

Mais il doit quand même exister des cas où utiliser un type paramètré par '? extends A' est util?

---

Dans plein de cas : le problème lorsque tu utilises Set<A> c'est que tu n'est plus du tout générique puisque justement fortement typé !





Prenons un autre exemple, mettons que nous avons une classe Person contenant principalement le nom et l'email de la personne (avec les accesseurs qui vont bien), et plusieurs classes filles qui gère des spécificités pour les clients, fournisseurs ou encore les employées via les sous-classes Customer, Supplier et Employee.


L'application ou les applications pourraient être amenés à utiliser plusieurs types de collections :

• Set<Person> lorsqu'on manipule plusieurs types de personnes différents.
• Set<Customer> pour le service client.
• Set<Supplier> pour la gestion des achats auprès des fournisseurs.
• Set<Employee> pour la payes...

Dans une classe utilitaire on voudrait permettre d'envoyer un simple mail à un ensemble de destinataire. On serait tenter d'écrire ceci :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

public static void sendMail(String text, Set<Person> recipients) {   Email email = ... // une classe qui gère les emails   for (Person p : recipients) { email.addRecipient(p.getEmail()); }   email.setContent(text); email.send(); }

---

Le problème c'est qu'on est fortement typé et qu'un Set<Customer> n'est pas un Set<Person>... On ne pourra donc pas utiliser notre méthode aussi facilement que possible et il faudra soit dupliqué du code, soit effectué diverses transformations plutôt inutile.


Or dans notre méthode sendMail() on se fiche de connaitre le type exact de la liste, du moment qu'il s'agit bien d'une liste de personnes...

En changeant simplement la déclaration du paramètre générique on corrige directement ce petit problème :

Code:

---

public static void sendMail(String text, Set<? extends Person> recipients) {

---

:arrow: On peut désormais utiliser notre méthode avec n'importe quel type de liste de personnes, quelque soit le type précis de la liste ;)

En contrepartie on ne peut pas modifier la liste mais c'est logique puisqu'on ne connait pas exactement le type de la liste !





Le ? super T permet exactement l'inverse, mais l'intérêt est un peu moins évident à comprendre...



Il ne faut pas oublier non plus qu'avec les méthodes Generics ont peut avoir des liens entre les types des différents paramètres. Par exemple la méthode Collections.copy() déclaré de la manière suivante :

Code:

---

public static <T> void copy(List<? super T> dest, List<? extends T> src)

---

:arrow: Permet de copier tous les éléments d'une liste de T (ou de type fils) vers une liste d'un type quelquonque mais parent de T (qui peut donc comporter des éléments du type T).

Ce qui fait que les types des deux listes ne doivent pas impérativement être du même type, mais doivent rester cohérente, par exemple ceci est possible :

Code:

---

1 2 3 4

List<Number> listNumber = ... List<Double> listDouble = ...   Collections.copy(listNumber, listDouble);

---

:arrow: Mais pas l'inverse !



Si on n'aurait pas utiliser les wildcard, et qu'on se serait contenter de ceci :

Code:

---

public static <T> void copy(List<T> dest, List<T> src)

---

:arrow: Le code ci-dessus n'aurait pas été possible et les deux List auraient dû être exactement du même type Générics...




Ce n'est pas forcément évident à comprendre, mais les wildcards ont un gros intérêt dans les Generics, et peut-être même que tu as déjà utilisé des méthodes les utilisant sans t'en apercevoir ;)

a++