Discussion :

[Uranne-jimmy]

Bonjour
Je suis en train de monter un programme qui simule un jeu de carte (pas classique), pour apprendre un peu mieux à gérer la notion d'objets, de Class.
Je me retrouve dans le cas où généralement, les cartes ont un effet sur les joueurs.

Premier problème dans l'ordre de conception : comment faire pour qu'un objet soit lié à sa création à un effet (événement ?), sachant que l'effet sera unique car lié à certaines variables.
Exemple lambda : carte1 fait piocher 3 cartes.
Si je crée un objet carte, nommé carte1, comment associer l'effet "piocher" et définir le nombre de carte (dans ma tête, l'effet est alors également un objet, mais un objet bizarre qui est en faite une action lié à un ou plusieurs paramètres dépendant de la carte ? Oo).

J'espère poser la question dans le bon forum, je code en effet mon truc en vb.net mais le problème semble plus général, mais malgré tout dépendant de la façon dont sont géré les objets selon les langages.

[worm83]

Il nous faudrais un peu plus d'explication pour t'aider, il nous faudrait au moins une partie du code de joueur et carte, ou un diagramme UML.

Comment instancie tu tes objets et où, ect.....?

Je pense que ce que tu cherche à implémenter est un pattern "observer", en .Net tu peux
- te lier à un EventHandler, ou un delegate (typé ou non),
- sinon tu peux faire une méthode de "contrat" qui lira un joueur à la carte tiré, à partir de là tu pourra faire appel à des méthode du parent ou du fils.

[Uranne-jimmy]

bonjour !
J'en suis au tout début, mon problème là est au niveau de la stratégie que je dois suivre pour être le plus propre possible.
Pour l'instant j'ai créé la classe Carte avec deux filles,sachant que j'ai deux types différents de cartes, deux défausses. La classe joueur n'est pas entamé.

J'ai regardé un peu les EventHandler. Si je peux rajouter des arguments ça pourrait être intéressant comme outil, malgré que j'ai du mal à comprendre toutes les mécaniques.
Imaginons des événements : onFlip, onActivate par exemple. Selon le type de cartes je peux lier ça à un événement différent ? C'est bien la différence entre EventHandler et l'event déclaré dans la Class ?

Si c'est ça c'est cool, mais vu la machine à gaz que ça va donner, j'ai pas l'impression que ce soit la méthode la plus simple pour moi d'agir.

Dans tout les cas je pense que mon petit projet va me faire faire le tour de vb.net ^^'

[mactwist69]

Je pense que tu te trompes un peu sur la logique....

Avant tout il faudrait faire le modèle de données (diagramme uml, table en BD) pour savoir où tu vas et quels sont les propriétés de chaque objet (carte, joueur, type de carte etc...)
Une fois cela fait, tu peux commencer à parler de code.

Et c'est là que tu te trompes :

Ce n'est pas l'objet carte qui a un événement de type "retourne trois carte"... ça n'a pas de sens.
Ta carte elle a des infos sur son rôle : "Carte type Je pioche 3 cartes".
Mais la carte elle fait rien.

Derrière, ton programme, lui va lire à chaque tour la carte sélectionnée et gère l'action a effectuer.

La carte est un objet, elle contient des données mais ne fait rien en soi par rapport à ton jeu.

La carte est utilisé par une le programme qui gère la partie !
Le programme gère l'ensemble des cartes du jeu, décide de qui joue, effectue les actions en fonction des cartes sélectionnées... etc

[worm83]

Il existe des EventHandler<T> ou t est un paramètre generique quelconque.

Ça à l'aire d'une machine à gaz effectivement quand il y a beaucoup d'event, mais c'est une habitude et en tant que dev .Net, on s’attend à ce genre de chose (instinctivement on va regarder si il y a pas un event pour s'accrocher), et puis c'est beaucoup moins lourd que la deuxième méthode que je t'ai proposé.

En tout cas TOUT le framework .Net est pensé ainsi, quand on doit faire remonter une information à un observateur , on le lie par un event, c'est une bonne pratique.

Regarde les tutoriaux sur les Événement et les délégués, ce sont des mécanisme extrêmement puissant (comme peux l'être un pointeur de fonction en c...).

D'une manière générale je t'invite à aller plus en avant sur le paradigme objet.
http://blog.xebia.fr/2011/07/18/les-principes-solid/

[wallace1]

Bonsoir,

Je rejoins nos assidus de l'O_O..

J'ajoute également que lors de ta phase d'analyse (avant la phase de codage) tu devras certainement faire ressortir un autre objet de type "Tapis de jeu" afin d'optimiser l'interaction entre tous les acteurs. En effet ce qui n'est pas dans les mains des joueurs doit se trouver sur le tapis .....

En effet UML reste une bonne approche pour modéliser un projet (tout le monde ne sera pas d'accord je le sais déjà ^__^). J'en discutai ici jadis pour un projet de bataille navale en VbNet :
http://proghelp.fr/projet-f67/batail...le-t448-7.html

A+

[Pol63]

pas tout lu mais je rejoins mactwist et wallace

après comme vu récemment sur un topic, il n'y a jamais une seule solution qui est propre et pratique
donc tu peux tenter d'écrire des choses juqu'à que ca te paraisse bien ^^

moi je verrais aussi une classe carte avec des propriétés, éventuellement une classe effet avec des propriétés et/ou des méthodes mais la carte doit pouvoir encapsuler ca peut etre ... sauf si tu veux plusieurs effets par carte, auquel cas il faut bien une classe effet et une collection d'effet sur la classe carte
une classe pour gérer la partie, qui elle irait lire les effets des cartes pour l'appliquer sur les joueurs, la pioche, la défause etc...
cette classe partie auront donc plein de propriétés et tout le code pour la gérer
et le tout avec un peu d'héritage ^^

les évènements doivent pouvoir être utilisés aussi, mais on peut dans certains cas s'en passer
une fois la carte à jouer choisit, si la carte sait dans quelle partie (notion de parenté) elle est, ou si elle peut l'atteindre par joueurproprietaire.partie elle peut alors appeler des méthodes sur la partie genre .jouercarte, et cette méthode fera le reste