Les generics, hors les types collection ?

Bonjour,

Les types génériques, ça sert à quelque chose ?
hors types collections où la effectivement, cela
prend (à mon avis) tout son intérêt ...

Je ne vois pas d'exemple autre qu'une utilisation
pour manipuler des collections d'objets ...

Merci de vos avis !

Ma réponse fait très con mais il y a de l'idée !


Eplucheur<T> =>
Un éplucheur ... de quoi ?

Eplucheur<Patate> =>
De patates pardi !

Eplucheur<Pomme> =>
Où alors de pommes pourquoi pas.

C'est surtout utile quand tu réalise une API qui utilise une classe dont tu ne sais que peu de choses.

Par exemple, je travail pour ma part sur une API de réseau, et je gère tout ça en fonction des "clients" qui sont connecté à ma plateforme.
Ainsi j'ai "NetworkPlateform<T extends Client>", "Connection<T extends Client>" ....
De l'extérieur, lorsque tu utilise ensuite Eclipse, tu fait une classe qui hérite la classe Client et toutes les méthodes qui gèrent normalement des Clients d'après l'API, vont pouvoir te renvoyer ton propre type d'objets.

Il est vrai que sans rien, une classe générique sera plus utilisée pour une liste, mais le mot clé "extends" est la pour faire des choses plus spécifiques.

Merci pour ta réponse. Après avoir lu ta réponse, je me demande ... comment aurais-je fait sans les generics ?

Un truc du genre :

Code:

---

1 2 3 4 5 6 7 8 9 10

class NetworkPlatform {   Client c;   NetworkPlatform (Client c_arg) {   c = c_arg; } ...... }

---

Et ensuite avec une class MonClient

Code:

---

1 2 3 4

class MonClient extends Client { ... }

---

je fais un new NetworkPlatform (new MonClient)

Tu vois où je veux en venir ? qu'apporte la généricité dans ton
exemple alors que l'utilisation de l'héritage (et du polymorphisme)
me permet dans la class NetworkPlatform de manipuler un objet
dont j'ignore la classe exacte ? Je sais juste qu'il s'agira
d'un "Client" ....
J'ai le sentiment que tu ne gagnes rien à utiliser la généricité
dans ton exemple mais je ne le connais pas suffisamment et
je dis peut être une bêtise ...

jean

Heu, j'aurais un petit peu de mal à expliquer pour ma plateforme de réseau mais avec l'éplucheur ça se montre très facilement !

Code:

---

1 2 3 4 5 6 7 8

public class Eplucheur<T extends Legume> { public Eplucheur() { }   public T eplucher(T legume) { //Met ici comment on épluche tes légumes return legume; } }

---

Tes éplucheurs, quand tu leur donne une pomme, au retour, tu n'as pas une carotte mais bien une pomme. ;)

Si ensuite tu te contente de faire :

Code:

---

1 2 3 4 5 6 7 8

public class Eplucheur { public Eplucheur() { }   public Legume eplucher(Legume legume) { //Met ici comment on épluche tes légumes return legume; } }

---

et que tu envoie une pomme, tu vas avoir besoin de faire un cast vers ta classe de pomme pour l'utiliser comme une pomme. De plus, rien ne dit que ton éplucheur sur un coup de tête ne vas pas te r'envoyer une patate.
Dans la première solution, le cast est implicite.

oups, citer au lieu d'éditer. C'est pas bon.

OK Grimly, je suis d'accord avec toi.
Dès lors que l'on a besoin de faire des put et des get, l'avantage
des generics est d'avoir un truc bien typé qui évitera au programmeur
de faire des casts, susceptible de générer des exceptions
au runtime.

Et c'est un peu le cas de ton type Eplucheur même s'il n'apparait
pas explicitement comme une classe Collection, on pourrait
presque l'apparenter à une collection de 1 élément ...

Je cherche en fait des exemples plus complexes et qui se détachent
vraiment de la notion de collection.
Je n'en trouve pas et tous les exemples de démonstration de generics
que je trouve sur le web sont basées sur des collections.

Par ailleurs, le seul bouquin que je connaisse sur les generics
est un bouquin qui présente à la fois collection et generics.

merci à toi pour tes réponses et exemples

jean

edit: adiGuba, désolé d'avoir oublié les balises et merci à toi !

De rien.


Dans tous les cas, demande toi de façon bête ce dont tu as besoin.

Quand tu as quelque part dans tes classes ".... de quelque chose", en travaillant sur un code que tu compte réutiliser (une API par exemple), tu y mettra le plus souvent un générique.

Les exemples ne sont pas nombreux et facile à trouver, mais tout au long de tes expériences, tu y sera confronté surement un jour.

Le générique, ca sert quand tu veux écrire du code "générique" (pour plusieurs types d'objets) sans avoir à constemment faire du typecasting sur les valeur de retour ou sur les paramètres. Les collections sont effectivement le cas d'utilisation le plus flagrant. Cependant, tu va retrouver aussi dans tes cas d'utilisation:

toutes tes classe qui recoivent des Objet d'un type X en paramètre et dont le type ne peux pas changer au cours de la vie de la classe qui le recois (exemple: l'eplucheur dans ton cas, on epluche pas une pomme avec un eplucheur à patate)
toutes les classes encapsulant une collection.


voici peut être un exemple plus explicite de l'eplucheur:

Code:

---

1 2 3 4 5 6 7 8 9 10

public Abstract class Eplucheur<T> { public Eplucheur(String marque){......} public abstract void epluche(T cible); }   public class EplucheurAPatates extends Eplucheur<Patate>{ public void epluche(Patate cible){ cible.retirerPelureEtYeux(); } }

---

Si t'avais fait ça sans génériques:

Code:

---

1 2 3 4 5 6

public class EplucheurAPatates extends Eplucheur{ public void epluche(Object cible){ Patate p = (Patate) cible; p.retirerPelureEtYeux(); } }

---

non seulement il te faudrait un typecasting pour chaque méthode prenant en paramètre une patate, mais en plus, rien n'indiquerait dans le code suivant:

Code:

---

1 2	EplucheurAPatate p = new EplucheurAPatate(); p.epluche("une patate");

---

Que l'appel à epluche est incorrect. Il faudrait attendre que l'exécution passe dessus pour s'en rendre compte, alors qu'avec les generique, l'incohérence apparait à la compilation.

Salut,

Je pense qu'il y a un abus de langage ici :

Citation:

---

Envoyé par tchize_

Si t'avais fait ça sans génériques

---

:arrow: Il ne faut pas confondre la généricités, qui consiste à utiliser un type générique pour effectuer des traitements, et les Generics qui permettent en plus au compilateur de vérifier le code.

:arrow: La généricité a toujours été présente dans Java, mais le gain que cela apportait était contrebalancer par la nécessité de caster/vérifier les types pour des traitements moins génériques...

Les Generics ont apporté un typage un peu plus fort. Le code reste générique mais on peut l'utiliser de manière typé, afin d'éviter les casts et les vérification de type et donc d'obtenir un code plus sûr (fini les ClassCastException en cas de mauvais usage : on a directement une erreur à la compilation ;))

a++

Il faudrait parler de "typage paramétré". D'ailleurs c'est comme cela que le présente Romain Guy dans son article.

Citation:

---

Envoyé par adiGuba

Je pense qu'il y a un abus de langage ici

---

désolé :aie: