Types génériques en Java.

[nworr 0]

Excuse moi de vous déranger, je crois que je vais poser une question bête, :

A quoi sert l'utilisation de la généricité alors qu'on peut utiliser le type Object ?

Je comprends mieux quand on fait un Personne

(P a un "vrai type" ) mais quand on fait un

tout seul ??

De ce que je crois me souvenir en C++ (je sais que gfx a dit que c'etait différent, je me permet une comparaison) les templates permettaient de faire (par exemple) des conteneurs "génériques" mais en java

un conteneurs d'objets suffisait non ?

L'apport de la généricité Java se situe-t-il alors au niveau d'opitmisation du code, de la refléxivité ? (c'est le nom ?? )

[Sharpshooter 0]

Le problème d'Object c'est que c'est trop générique justement. Si on travaille sur le type Object on peut y mettre tout ce qu'on veut (puisque tout est objet en Java).

On ne peut pas savoir ce qui va se passer dans une classe ou une méthode et on risque à un moment ou un autre de mélanger différents types d'objets. Par exemple stocker dans une collection de Personnes des objets de type Véhicule. Alors que quand le type est définit au préalable c'est ce type que l'on utilise et pas un autre.

Pour résumer : avant la généricité c'était tout ou rien. Trop prédéfinit ou trop général.

Soit on avait une méthode :

public Integer toto(Integer i){ }

et on ne traitait que les Integer.

Soit on avait une méthode :

public Object toto(Object i){ }

et on traite tout et n'importe quoi quitte à changer de type d'objet en cours de route.

Avec :

public  retour toto(T i){ }

on choisit un type à l'appel de la méthode et on n'en change plus.

[nworr 0]

Mais oui que je suis con !!! merci beaucoup !

Faire du php toute la journée, ça fait oublier les bases :sorry

[Gfx 0]

Sharp, eh bien alors il faut écrire cela :

class Personne
 {
 public static  Personne creer(T profession) {
   return new Personne();
 }
}

Note bien que je ne vois pas l'intérêt de faire ça

[Sharpshooter 0]

Ben en fait puisque j'ai une classe Personne du type : Personne

ou P est un objet Profession...

Pour construire une personne complète je dois faire :

toto = new Perso();

toto.profession = new Medecin()

Et ca me parait bizarre qu'on ne puisse pas faire plus simple, soit : toto = new Perso() avec la profession créée automatiquement.

Faudrait peut-être que je regarde au niveau des jokers de types. J'ai pas encore bien compris les applications.

[Gfx 0]

Ce n'est pas bizarre. Tu veux utiliser les generics d'une manière qui n'est pas celle prévue à l'origine. Encore une fois, ce ne sont pas les templates du C++. Si tu veux créer ton médecin automatiquement tu peux faire : new Perso(Medecin.class) mais l'intérêt est minime. D'ailleurs, as-tu besoin des generics ? J'ai comme un doute )

[rjds 0]

et ben vive le C !!!

[Sharpshooter 0]

Si je comprends bien Gfx, tu rejoince ce que disais Thev. Arg ! Tout le monde est contre moi !

Bon. Imaginons que je passe par une classe Medecin, une classe Enseignant, etc. qui toutes héritent de Personne. Pendant toute la durée de l'application je vais traiter des objets Personne et de temps en temps il faudra que je teste si bidule est médecin ou pas. Ca me parait tordu. J'ai l'impression de prendre le truc à l'envers en faisant ça.

Avec les types génériques, j'ai des objets Personne dont le membre profession est un objet de type Medecin, Enseignant ou autre. Ca me parait plus simple et plus clair (à part l'histoire de la construction de l'instance).

Bon vous allez me dire que je chipotte parce que ce n'est pas très fatiguant de faire : toto = new Personne(); toto.profession = new Medecin();

[thev 0]

Ben non, tu as un objet Personne, qui a un membre de type Profession, Profession étant l'interface définissant les méthodes communes de toutes les professions.

Avoir un objet Personne composé d'un objet profession, ça me paraît une bonne approche. C'est que je disais dans un post plus haut.

Je le redis, je trouve la solution generics pas très adaptée.

@+

[Gfx 0]

Comme thev. La composition Personne->Profession me semble très bien mais les generics pour ça... Note que c'est mal de vouloir faire toto.profession = new Medecin()

D'ailleurs, cela t'apporte quoi d'avoir la profession sous forme d'une vraie classe ? Tu ne peux pas utiliser une enum ? Ou te passer complètement des generics ?

// enum
Personne p = new Personne(Profession.MEDECIN);
// classe
Personne p = new Personne(new Medecin());
// ou p.setProfession(new Medecin()) si tu préfères

Je ne vois vraiment pas pourquoi Personne devrait être générifié par une profession.

[Sharpshooter 0]

Je comprends bien que c'est mal de faire profession = new Medecin() c'est pour ça que j'aurai voulu initialiser profession dans le constructeur de Personne.

C'est vrai que je pourrais utiliser les énumérations vu que les énums sont quasiment des classes avec constructeur, méthodes, etc. Mais j'aime pas trop l'idée d'une énumération qui finit par être aussi polyvalente qu'une classe. Autant déclarer ouvertement une classe. M'enfin c'est peut-être la solution la moins pire.

Par contre je trouve que l'utilisation des type génériques n'est pas si mal que ça ici. A ce que j'ai compris les classes génériques ça sert à dire "dans cette classe il y a des membres dont le type sera variable d'une instance à l'autre". C'est typiquement le cas des personnes et des professions non ? Pourquoi faudrait-il éviter les classes génériques ?

La logique voudrait que j'utilise l'héritage (Personne contient Médecin qui hérite de Profession) mais alors la variable profession serait du type Profession (trop général) ou alors du type Médecin ou Enseignant ou... et on revient sur les types génériques.

Pour vous donner une idée, à chaque profession correspond un certain nombres d'initialisations et d'affichages. J'ai donc dans la classe Medecin et dans la classe Enseignant une méthode initialiser() mais les deux méthodes ne font pas la même chose.

Avec les enum je pourrais m'en sortir mais je ne couperais pas à un truc du genre "switch (profession) case MEDECIN : blabla; case ENSEIGNANT : blabla; et j'aime pas cette formulation.

[PoP 0]

Et en LISP ça serait pas mieux?

:run:

[Gfx 0]

Pour ton "p.profession = ...", tu peux bêtement utiliser un constructeur (new Personne(new Medecin())) ou un mutateur (p.setProfession(new Medecin())).

Le problème ici c'est qu'une Personne ne contient pas un médecin. Une personne *est* un médecin et c'est là que ton utilisation des generics me semble faible.

Je ne vois pas en quoi manipuler tes professions sous forme de type Profession serait gênant. L'héritage et la redéfinition de méthodes te permettra de résoudre ton problème.

J'ai donc dans la classe Medecin et dans la classe Enseignant une méthode initialiser() mais les deux méthodes ne font pas la même chose.

Et alors ? Si tu as Profession p = new Medecin(), appeler p.initialiser() (ce qui est mal d'ailleurs appellera la version d'initialiser définie dans Medecin. De même, p = new Enseignant() suivi de p.initialiser() appellera la méthode initialiser() de Enseignant. Les generics ne servent *à rien* dans ce cas.

J'utilise J2SE 1.5 depuis sa sortie et j'ai rarement eu besoin d'implémenter des generics. Je persiste à croire que tu ne maîtrises pas les concepts de la POO

Tu peux implémenter une solution à ton problème sans generics, sans enum et sans switch, uniquement par héritage, composition et redéfinition de méthodes.

[Sharpshooter 0]

Pour ton "p.profession = ...", tu peux bêtement utiliser un constructeur (new Personne(new Medecin())) ou un mutateur (p.setProfession(new Medecin())).

Oui ça j'avais compris je cherchais une autre solution.

Je ne vois pas en quoi manipuler tes professions sous forme de type Profession serait gênant. L'héritage et la redéfinition de méthodes te permettra de résoudre ton problème.

Je ne sais pas. Ca me paraissait bizarre de créer x sous-classe de Profession et finalement de ne manipuler que des objets Profession.

Si tu as Profession p = new Medecin(), appeler p.initialiser() (ce qui est mal d'ailleurs

Ouai enfin quand je parlais d'initialiser je parlais d'une méthode comme une autre pas d'une méthode qui initialiserait l'objet.

J'utilise J2SE 1.5 depuis sa sortie et j'ai rarement eu besoin d'implémenter des generics.

Je ne comprends toujours pas cette réticence à utiliser des types génériques. Même si effectivement dans ce cas là tu m'as convaincu que l'héritage serait aussi bien.

Je persiste à croire que tu ne maîtrises pas les concepts de la POO

En même temps si je maîtrisais correctement je ne prendrais plus vraiment de plaisir à programmer et je ne viendrais pas faire chier le monde avec mes questions.

Tu peux implémenter une solution à ton problème sans generics, sans enum et sans switch, uniquement par héritage, composition et redéfinition de méthodes

Ca marche très bien avec une classe générique même si je comprends que conceptuellement c'est pas terrible. Je vais modifier ma classe pour utiliser l'héritage.

[Gfx 0]

Mais je n'ai aucune réticence à utiliser les generics. J'ai écrit une biblitothèque entièrement générifiée (fuse.dev.java.net) mais leur usage est assez limité, et dans ce cas il n'est absolument pas nécessaire.

Les generics ne font qu'éviter des casts. Si tu déclarais une Personne, tu ne pourrais pas appeler des méthodes de Medecin dans la classe Personne, car pour Personne le type P sera une simple Profession.

[PoP 0]

En même temps si je maîtrisais correctement je ne prendrais plus vraiment de plaisir à programmer

ah parce que pour toi c'est plaisant de ne pas maitriser un sujet et d'en chier pour arriver à un résultat performant? Rappelle-moi de ne jamais bosser avec toi.

[Sharpshooter 0]

Tu préfères bosser avec des gars qui râlent dès qu'ils bloquent sur un truc et qu'il leur faut en apprendre plus pour avancer ?

Je m'amuse plus en programmant un truc qui m'en fait baver qu'en développant un démineur !

[PoP 0]

Il y a une différence entre maitriser un langage/une technique de prog et ne pas maitriser le sujet dans lequel on l'applique...

Pour ma part j'adore bosser avec des gens qui maitrisent très bien l'environnement J2EE pour les faire bosser sur des thematiques qu'ils ne connaissent pas du tout (reco vocale, bus applicatifs,...).

De mon humble point de vue, la phase "je m'amuse car j'apprends un langage" doit s'arrêter à la fin des études...sinon ça devient assez difficile de quantifier ta productivité, et donc ton prix de vente non? (et par extension ta valeur, donc ton salaire)

[Gfx 0]

Han PoP est devenu relou Oo

[PoP 0]

Je l'étais pas déjà?

[Sharpshooter 0]

Arg ! C'est bien les geek ça. Tout le monde n'a pas appris la programmation pendant ses études et afin de devenir développeur. Je ne suis ni étudiant en informatique ni développeur.

Je programme donc pour le plaisir d'apprendre (à programmer) et pas pour être productif.

[Gfx 0]

Sharpshooter : Ne nous met pas dans le même panier, je pense que tu as raison hein. D'ailleurs, je trouve ça même plus sain de vouloir apprendre des nouveaux langages/techniques que l'approche de PoP

/me jette un "The Pragmatic Programer" by Hunt and Thomas sur la tête de PoP

[Sharpshooter 0]

Non non quand je disais "les geeks" je parlais des geeks en général pas de toi en particulier.

[PoP 0]

Gfx c'est pas un geek, c'est Über-nerd, cépapareil!

Oui bon ok, j'ai été un peu extermiste dans mes propos. C'est assurement niais de se cantonner à un périmètre de compétences et de ne pas vouloir aller s'essayer à d'autres choses.

C'est juste que dans ce que j'avais cité des propos de Sharp j'avais retenu "je bande en codant que si je maitrise pas ce que je fais", qui me semblait un poil fonfon quand même.

Bon, sur ce je vais aller prendre mes cachetons, l'infirmier m'appelle.

[momo 18]

donc si je comprends bien la situation : pop est jaloux parce que pour qu'il puisse bander en codant il doit prendre ses cachetons ?

...