Salut,

en fait j´ai un petit soucis d´implémentation lol^^
Admettons :
J´ai 4 joueurs à gérer sur un écran, avec chacun des touches sur le clavier qui lui correspondent.

J´ai d´abord procédé ainsi :
Une classe players et ensuite 4 pointeurs (ex p1,p2,p3,p4) qui pointe sur celle-la.
Bon, mais vient le problème de la gestion des événements; en effet, chaque joueur utilise d´autres touches. Je me suis dit, "ainsi c´est faisable, mais ce sera cheni".
J´ai donc pensé à créer ma classe players, mais virtuelle, que je remplacerais ensuite tour à tour par 4 classes publiques (ex p1,p2,p3,p4).
Mais je me suis aussi dit "ça fais bcp de classes pour peu de différences (événements)".
Le quel des raisonements est le plus logique?
Le 2e me tente bien, mais me semble un peu "lourd"...
Qu´en pensez vous?

Merci d´avance pour votre attention à mon problème !

Oui, donc au cas ou vous auriez pas compris (dsl c´était pas clair), ma/mes fonction(s) d´event se trouve(nt) à l´intérieur de la classe players (et donc des classes publiques dans le cas d´une classe players virtuelle).

Moi je te propose la structure suivante si tu veux absolument faire du polymorphisme :

tout d´abord un tableau de players (passons tout de suite aux pointeurs) :
Player* T[4];

Puis :

class Player
{
...
virtual void EventControl()=0; // virtuelle pure
};

Ensuite, si les joueurs sont différents (pas gérés pareil) tu peux tres bien faire :

class SpecialPlayer : public Player
{
void EventControl();
};

class AnotherPlayer : public Player
{
void EventControl();
};

Tu instancies ainsi :

T[0] = new SpecialPlayer();
T[1] = new AnotherPlayer();

et ainsi, tu peux appeler sans complexe l´une ou l´autre des fonctions qui branchera sur la bonne

T[0]->EventControl();

Mais bon, moi je ne te conseille personnellement pas de polymorphisme... C´est sorir l´artillerie lourde pour quelque chose qui n´en vaut pas la peine je pense : car tes players ne seront peut etre pas radicalement différents, bref !

Je dirais aussi que ton raisonnement n´est pas logique.

Si tu as 4 joueurs, alors tu dois avoir 4 objets. Pour chaque objets, tu peux definir une fonction de lecture des touches, et pis voila.

Ouais mais c´est interessant pour s´entrainer au concept de polymorphisme ;)
J´ai lu la proposition de JYY avec beaucoup d´interet, chui pas encore super calé sur le sujet.

ou encore mapper toutes les touches du clavier vers une fonction. (oui j´adore les pointeurs de fonction)

JYY > c´est exactement ce que j´ai écris sur ma feuille de papier
Sinon, lapintade, j´ai plus résonné comme fenix, je suis en pleine lecture de mon bouquin, et j´aimerais bien mettre en pratique ce que j´ai appris... dans des projets pas trop compliqués.

godrik > je retiens le truc

´suis pas d´accord sur l´utilisation du polymorphisme dans ce cas la ; vous polymorphez pour redefinir 4 touches a la noix... Si vous voulez polymorpher, faites le sur un truc qui le justifie, comme par ex des joueurs humains, et des joueurs IA.
Ce que je vois comme design, avec les elements fournis :
- polymorphisme joueur > joueur humain/machine, si utile pour le jeu
- un DP Strategy sur la methode d´input, pour gerer plusieurs entrees de manieres transparentes
- delegation du traitement via un managaer qui convertit des inputs en actions jeu, en fonction d´un context
- si besoin, specialisation specifique via traits class avec templates
- et comme ca flaire bon tout un tas d´actions "symetriques" (ex. collisions joueur/joueur, joueur/obstacle, etc.), prevoir du double-dispatching pour rendre ca souple a utiliser

(bon, comme toujours, si certains s´interessent, il suffit de googler joyeusement pour trouver toutes les infos detaillees sur tous ces concepts..)

(au passage, on n´a pas de classes anonymes en C++, et ce genre de pb se pose souvent ; en general une sorte de strategy/delegation via composition/demotion avec couplage faible permet de resoudre le pb de maniere tres souple, en gardant en archi de classes simple, flexible avec peu d´heritage ; je recommande le livre Large Scale C++ Software Design pour ceux que ces considerations interessent ; a reserver a ceux ayant deja une bonne experience de software architect sur des projets d´une certaine envergure)

"j´aimerais bien mettre en pratique ce que j´ai appris"

Je suis d´accord avec LGV. Ok pour appliquer ce que tu es en train de voir mais pas ok pour appliquer ca n´importe comment.
La philosophie objets, c´est savoir choisir ce qu´il y a de mieux pour un probleme donné. Les mauvais programmeur sont ceux qui font des trucs "C++ advanced" juste pour le plaisir de les faire meme si c´est pas utile.

Keep it simple.

j´utilise souvent de l´heritage/polymorphisme a un niveau dans ce que je fais, je definit ainsi une classe "borne inferieure" (qui ne sait rien faire) que je derive suivant les differents algorithme de calcul ed borne inferieur que j´ai.

de facon general si on peut resumer la difference entre deux objets par la valeur differente d´une variable, il ne FAUT PAS utiliser le polymorphisme.

"mauvais programmeur"

moi pas vouloir mauvais programmeur être

Je vais keeper ça "easier" alors

Lis bien ce que j´ai mis a la fin de mon poste : bien que je te propose une solution a ton probleme si tu veux faire du polymorphisme, je te dis bien que je ne te conseille pas de faire du polymorphisme pour ce cas la.

Ouep, j´avais lu...
Mais avec les messages suivants, qui renforçaient cette idée, j´ai compris que le polymorphisme était pas l´idéal !
En tout cas je suis bien content d´avoir posté avant de m´embarquer dans qq chose d´illogique.
Je vais faire plus simple.

Genre :
Player1 = new Players();
Ensuite :
Player1->Event(P1);

Finalement :
Players::Event(int player)
{
if(player==1)
{
//...
}
else if(player==2)
{
//...
}
//...
}

J´avais pensé à ça tout au début, y a mieux ou pas?

thx

c´est "ignoble".. Players jouerait le role d´un "manager" qui fait tout au cas par cas > contraire a l´optique objet ou chacun est responsable de ses propres elements.

(note : pour autant je ne suis bien sur pas oppose au principe des managers singletons, mais des cas qui le justifient..)

Oki, tu proposerais quoi toi?
(j´aimerais bien avoir plusieurs solutions )

Ne rien faire.
Voila t´as plusieurs solutions.

j´ai deja expose mon point de vue sur la question plus haut

En effet, excuse moi.
Le seul prob c´est que j´ai compris à peine la moitié des termes que tu as utilisé (j´ai peut être abordé les techniques mais en tout cas connais pas ces noms).
J´ai pas le temps d´aller sur google mtn, je vais partir, j´irais essayer de voir demain.
merci ++