Bonjour,
 
 
je suis en train de réaliser un jeu de cartes, et pour cela, j'ai réalisé une classe CCard abstraite, qui est ensuite dérivé en plusieurs classe fille, une pour chaque type de carte du jeu (c'est un jeu de vaisseaux spatiaux) : CCardShip, CCardBlast, CCardOperation.
 
J'ai besoin, dans une de mes classes (CLibrary), d'avoir une méthode Add, qui prends en paramètre un objet d'un deds trois types ci-dessus, et l'ajoute dans la pile de cartes qui lui est associé : il y a en effet trois pile de cartes dans le jeu.
 
J'aurais besoin d'utiliser cette méthode Add de cette manière :

class frame_add_card
{
    CCard card_;
    CLibrary lib_ = new CLibrary();
 
    [...]
 
        // action déclenché sur le bouton OK (un bout de Swing :)
        public void jButtonOk_actionPerformed(ActionEvent e)
        {
            if (this.jRadioShip.isSelected())
            {
                CCardShip a_card = new CCardShip();
                [Set des valeurs de la carte];
            }
            else if (this.jRadioBlast.isSelected())
            {
                CCardBlast a_card = new CCardBlast();
                [Set des valeurs de la carte];
 
            }
            [etc. ...]
 
                card_ = a_card;
        }
 
    [...]
 
        // ajoute la carte dans la bibliothèque
        public void GetCard ()
        {
            lib_.Add(card_);
        }
 
}

 
Ce que j'aimerais, c'est pouvoir avoir une seule méthode Add, surchargée éventuellement (surement même ), et que suivant le type de a_card, la bonne méthode est appelée, et la carte est effectivement ajoutée dans la bonne pile.
 
Le problème, c'est que actuellement, ca marche
En effet, je suis obligé de créer une méthode Add(CCard a_card); , sinon, j'ai une erreur de compilation.
Mais si je crée cette méthode, alors, c'est toujours elle qui est appelée, au lieu de celle qui correspondrait au type de la carte que je veux ajouter ...
 
 
Voilà, j'espère que quelqu'un pourra m'aider, ou au moins, m'éclaircir sur la marche à suivre
 
Merci !

ben post les erreurs de compils
(je relis ton bins en attendant)

du Java MFC

bon ok. Vu comme t'as fait ca y'a pas trop moyen
 
le pb c'est que tu stockes dans ta classe un CCard. Donc tout ce que le compilo peut savoir la, c'est que l'objet est de type CCard.  Et quit c'st qui resoud les pb de surcharge ? le compilo. Donc y'a pas moyen de faire ce que tu veux.
 
par contre,pas la peine de te suicider, tu peux t'en tirer, soit en castant ton CCard en CBlastCard, regarder si tu te manges une ClassCastException, si oui reassayer en CShipMachin etc etc sinon avec les instanceof

 
Ben j'ai pas d'erreur, c'est juste que ca fait pas ce que je voudrais que ca fasse

J'vais essayer de condenser mon problème

ou alors tout simple dans ta classe tu te met un pety entier qui decrit le type de la carte (0 = ship....) et ensuite tu fais tes test sur cet entier
 
'fin bon y'a ouainte mille solution

Oké
 
Pour ta première soluc, je cast où ? au moment ou je fais card_ = a_card;, parce que après, en fait, je sais pas quel est le type de card_ ...
 
Et pour le coup deds entiers, si c'était aussi simple que mon exemple, j'y aurais déjà pensé, mais en fait, c'est encore plus compliqué que ca

Juste parce que je préfixe mes classes par C ?

 
tu peux faire tout ca soit avant d'appeler ta fonction, soit dans la fonction appelée (ton add machin)
mais le cast c pas le plus beau, regarde le isinstance (si c bien ca le mot clé)
 
pour la partie en gras : toi non, mais Java si (il garde les infos sur les type de ses objets pendant qu'il tourne, ca permet justement les trucs genre ClassCastException)

euh les _ dans tous les sens aussi, des majuscules partout sauf là où il en faudrait vraiment

 
nan, les _  en fin de nom de variable c'est pas du MFC, MFC c'est m_

ben les mecs ils ont pas du lire bien leur spécification, parce que le m_ c'est quasi universel sauf chez les programmeurs MS, dans leur code c'est toujours le concours de celui qui en mettra le plus devant ou derriere (j'ai meme dejà vu des __bidule, évidemment ça pétait tout puisque les identifiants __ sont réservés

 
Pour avoir le type de l'objet, ya une méthode getClass, je peux peut-être me démerde avec ca ...
Mais ca retourne un type "Class", je le compare comment avec celles que j'ai ??

 
Ben les _, je les mets à la fin des membres privés d'une classe, et les majuscules, ben au début de chaque mot
Qu'est-ce qui te plait pas dans mes majuscules ?

c'est parfaitement illisible et on peut pas faire un truc plus source d'erreur

Ouais, je trouve ca plus lisible qu'un truc tout de la même casse ...

enfin bon là n'étais pas la question

Certe, mais si je programme vraiment comme un pied, et que je suis le seul à pouvoir relire mon code, c'est pas forcément mieux non plus. Tes conseils sont donc les bienvenus

bah laisse tomber cette notation idiote CClasse. mets des majuscules aux noms de types, etc et lis le document Java Coding Style  
http://java.sun.com/docs/codeconv/

 
le instanceof est quand même préférable, hein
 

nan mais vraiment, utilise instanceof !
 
ex : if (uneVariable instanceof String) { ... }
 

mais bon, y a des convention de codage en Java ...
 
faux-edit : grilled by taz
 

tout a fait.  
Par exemple, tu peux aussi stocker tes cartes dans différentes variables (chacune du type qui va bien) plutot que dans une seule (card_) du type CCard ...

 
c'est un peu ce que je dis un peu plus loin

ouais ouais j'ai vu, mais le fait même de penser au coup du cast + try/catch m'a totozé  

 
ben y'en a visiblement bien qui font des while(1) sur un parcours de tableau et attendent la OutOfBound
 
de tres bon

mais arrête de dire des trucs comme ca, ils vont t'entendre !!!

 
d'ailleurs perso je test pu sur nul, j'attaque comme un bourrin et j'attends recuperer la NullPointerException

Tu viens de voir pourquoi le pattern Visiteur existe, félicitations.  
Juste un petit détail technique, la "bonne" solution ne nécessite ni surcharge ni "instanceof" ni cast ni rien qui mette le système de types en vrac, contrairement à ce que je lis au-dessus, et dans l'esprit dans lequel tu étais parti.
 
Petit rappel : on ne demande pas son age à une vielle dame, par contre, elle peut te le donner spontannément (ce qui se traduit par : on fait pas un switch/case sur getClass ou sur instanceof). La solution repose entièrement sur le lien retardé des méthodes.
 
quelques références :
 
http://c2.com/cgi/wiki?VisitorPattern
http://128.42.6.89/JavaResources/D [...] attern.htm
GoF (Gamma, Helm, Johnson, Vlisside) Design Pattern page 387 (dans le version française).
 
Je ne te donne pas le code pour ton cas, mais juste quelques pistes : tes cartes sont les Visités, le truc que tu appelles CLibrary (il me fait flipper ce nom, je sens qu'il y a un pb dans ta conception) est le visiteur.
 
Voilou, essaye de grenouiller un peu avec ses infos et vient poser des questions.

Bon, j'ai jeté un coup d'oeil au pattern Visiteur, et c'est vrai que ca à l'air assez puissant peut-être trop pour ce que je veux faire. Je vais le relire pour bien tout comprendre.
 
Pour ton coup de flip sur CLibrary (qui s'appelle maintenant Library d'ailleurs ...) :
en fait, le bout de code que je vous ai filé reprends en gros ce que je veux faire, mais pas le code exact, c'est déjà assez compliqué comme ca (c'est presque plus dur de synthétiser son problème que de le résoudre )
 
Library, c'est ma classe qui représente la pile de cartes (la bibliothèque, en langage "joueur" ). Je l'ai concu comme ca : j'ai une classe StackCard, qui encapsule une LinkedList, et possède des méthodes Pop, Push, PushBottom, Randomize
 
et une classe Library, qui encapsule StackCard, de manière à avoir des méthodes plus parlantes en terme de jeu (Draw, Put, Shuffle)
 
 
Voilà quoi.
Bon, je me replonge dans le pattern Visiteur pour voir si ca me convient
 
Merci de vos réponses

Crois-moi c'est le pattern conçu pour ton cas. Par contre, au début c'est assez chaud de voir quel pattern sert à quoi.

pas toujours "presque" d'ailleurs

Cool, ca marche super bien avec en utilisant le pattern.
 
J'ai donc rajouter une méthode dans les classes Card* correspondant aux objets que je voulais ajouter dans mes Library.

 
puisqu'en fait c'est CardSet qui ajoute dans les Library (j'ai aussi renommer la méthode que je voulais surcharger, mais je sais pas si c'était obligé).
 
Et j'appelle cette méthode simplement par :

 
Bon, ca reprends pas vraiement le code que j'ai posté en premier post, mais on fait le lien facilement ... (j'espère   )
 
Merci

félicitations. C'est exactement ça.
 
 
heu juste un détail : en général on ne surcharge pas, on met directement le nom du type dans la méthode.
par exemple :

ça permet de voir directement en regardant le visiteur de savoir ce qu'il visite (dans les résumés).

Ok, j'vais corriger ca
 
 
Bon allez, maintenant, je me mets à DOM

mais ca oblige à ajouter du code dans un objet en fonction de son utilisation et pas en fonction de sa nature
 
A moins de wrapper, mais bof, quoi
 
je continue à penser que de garder différentes variables pour stocker les différentes cartes était une meilleur solution ...

Je vois pas trop ce que tu veux dire par là ... Tu peux détailler stp ?
 
 
Sinon, pour les différentes variables, j'y avais pensé, mais en pratique, dans mon code, ca peut pas marcher
 
Enfin bon, le problème n'est pas ultra critique hein C'est pas une appli temps réel, ni en jeu 3D ultra sophistiqué

non, un code supportant sa relation avec les autres objets.

ouais ben c'est bien ce que je dis ...
 
à partir du moment où il avait fait son objet et que, après coup, quand il doit l'utiliser d'une certaine façon il doit modifier son objet c'est qu'il y a un problème : soit son objet manquait de fonctionnalité à la base, soit il veut l'utiliser d'une mauvaise façon.  
Le pattern dont tu parlais tend à adapter un objet à chaque nouvelle "utilisation". Si cette "utilisation" fait partie du rôle de l'objet, ok. Mais dans le cas de multani-1, j'ai pas l'impression que ce soit opportun.
 

ben moi je pense que c'est opportun, on fait quoi ? duel au petit jour ? Si les règles du jeu disent que les différent types de cartes doivent être dispatchés sur des tas différents, alors il y a une relation dans le modèles de domaine entre les tas et les types de cartes. Qu'il ait ignoré cet aspect dans un premier temps est normal, il construit son truc peu à peu, capture de nouvelles abstractions progressivement, par refactoring itératif. Au bout d'un moment il est tombé sur une truc qu'il n'avait pas encore pris en considération.
 
de toutes façons il n'existe pas d'autre arrangement, même un instanceof est une forme dégénérée de Visiteur, dont on aurait élimité toutes les sécurités et dont on aurait rompu la règle de l'expertise.

c'était juste mon avis ...
 
je tiens pas à avoir LA vérité, moi ...