Problème de logique objet

Bonjour,
Depuis un bon moment sous vb.net, je décide de passer voir Mr c++
Je me suis it en tête de recréer un ancien projet que j'avais du faire en C il y a une long moment.
C'était un petit jeu avec des combattants, à l'époque j'avais utilisé des listes chaînées. Mais bon, avec le passage en vb.net, j'aimerais bien utilisé la poo comme il faut.
Pour l'instant je suis partis avec une classe personnage, qui possède trois classes filles(humain,elfe et nain), et maintenant je voudrais créer une classe groupe, avec une méthode ajout Personnage
Mais là je suis perdu, comment vais-je enregistrer les différents personnages, sachant que ce sont des instances des classes dérivées que j'aurais.
Merci de votre aide

Le polymorphisme.
Mais il faut utiliser des pointeurs.


Par exemple:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

#include <list>   classe Groupe { std::list<Personnage *> membres;   template<class T>ajout_membre(); };   template<class T>ajout_membre() { T *nouveau_membre = new T(); Personnage gen = dynamic_cast<Personnage *> (nouveau_membre); if ( gen != NULL) { membres.push_back(gen); return; }   //sinon il y a une erreur, T n'est pas dérivée de Personnage delete nouveau_membre; }

---

Et pour créer un nain:

Code:

---

groupe.ajout_membre<Nain>();

---

Edit:
Cependant, si tu ne connais pas ces techniques, tu as surement d'autres questions, n'hésite pas à les poser.

En mode supposition ^^ :
Je suppose que c'est bien membres qui me permettra d'accéder à mes objets, en fait <list> permet en quelque sorte d'obtenir un tableau indéfini, auquel on peut rajouter un élément sans redéfinir le tableau avec le .pushback

Je pense avoir compris la mécanique, Néanmoins je ne comprends pas l'utilsiation de la méthode ajoutmembre, groupe.ajoutmembre<Maclasse> , Hors la fonction n'admet aucun paramètre, j'ai bien vu que <Maclasse> n'était pas entre (), mais cela me perturbe à vrai dire.

en tout cas merci beaucoup, juste si tu pouvais définir plus préciseamment la mécanique de list, et commenter un petit peu le code de la fonction ajoutmembre, histoire que ce soit bien clair dans ma tête, pour que cet exemple puisse me resservir.
Un très très grand merci à toi

Salut,

Euh je ne suis pas certain que lui montrer directement un code avec templates et dynamic_cast soit très intéressant.

Groupe.h :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

#include <vector>   class Personnage;   class Groupe { public: Groupe(); ~Groupe();   void ajouter( Personnage* personnage );   private: std::vector< Personnage* > personnages_; }

---

Groupe.cpp :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

#include "Groupe.h" #include "Personnage.h"   Groupe::Groupe() { }   Groupe::~Groupe() { for( std::vector< Personnage* >::const_iterator it = personnages_.begin(); it != personnages_.end(); ++it ) delete *it; }   Groupe::ajouter( Personnage* personnage ) { personnages_.push_back( personnage ); }

---

Utilisation :

Code:

---

1 2 3 4 5

#include "Groupe.h" #include "Nain.h"   Groupe groupe; groupe.ajouter( new Nain() );

---

2 ou 3 trucs au passage :
. en fait on utilise très rarement des pointeurs nus en C++ mais bon c'est peut-être une étape future
. le groupe va désormais manipuler de manière uniforme les nains, humains, etc.. à travers l'abstraction Personnage
. à mon avis c'est une erreur de faire des classes Nain, Humain, etc.. ce sont sans doute des données et donc des configurations différentes de la classe Personnage, mais pas très grave dans un premier temps
. en général on utilise des vecteurs par défaut (plutôt que listes)

MAT.
(edit : mélanger français et anglais j'ai du mal...)

Bon bah là je crois qu'on va me tordre le cou
je viens de comprendre si cela est correct que:
Groupe::ajouter( Personnage* personnage )
{
personnages_.push_back( personnage );
}

en fait le pointeur sur personnage peut accepter un pointeur sur le type fille de personnage, si en effet cela est vrai, alors je m'excuse car cela devient bien plus clair pour moi, alors que... c'est ma notion objet qui est encore bien trop faible

EDIT: je viens de voir l'utilisation des vecteurs, et dire que je me casser la tête en C à faire des listes chaînées :s

Merci à vous, Merci beaucoup

Citation:

---

Envoyé par mathrb

Bon bah là je crois qu'on va me tordre le cou
je viens de comprendre si cela est correct que:
Groupe::ajouter( Personnage* personnage )
{
personnages_.push_back( personnage );
}

en fait le pointeur sur personnage peut accepter un pointeur sur le type fille de personnage, si en effet cela est vrai, alors je m'excuse car cela devient bien plus clair pour moi, alors que... c'est ma notion objet qui est encore bien trop faible

EDIT: je viens de voir l'utilisation des vecteurs, et dire que je me casser la tête en C à faire des listes chaînées :s

Merci à vous, Merci beaucoup

---

Oui, on peut accepter des pointeurs de classes filles. Pour obtenir la conversion de la classe mère vers la classe fille, on fait:

Code:

---

ClasseFille *objet_fille = dynamic_cast<ClasseMere *> (objet_mere)

---

Mais il faut généralement vérifier que le pointeur obtenu n'est pas NULL (échec de la conversion).

Regarde la FAQ C++ sur le polymorphisme pour en savoir plus.

Merci à vous 2
Si possible j'aimerais juste,Mat007, que tu m'explique pourquoi est-ce une erreur de faire les classes Humains, Nains...
je suis partis de ce modèle:
Un personnage possède un nom, des points de vies, une mainère de recevoir les dégats, et une manière d'attaquer
Une "race" possède les mêmes attributs et méthodes si ce n'est que je me sert du polymorphisme(depuis que vous m'en avez parlé) pour la méthode d'attaque.
Et finalement mon groupe qui a un nom, auquel on peut ajouter des combattants

Salut,

La premiere question à se poser serait peut être de savoir s'il est réellement intéressant de faire dériver nain, humain et elfe de la classe personnage...

Bien sur, je ne disconviens absolument pas qu'il y a une différence de taille entre les trois... mais pas si on les regarde comme "personnage".

Ce n'est peut être qu'un point de vue sémantique, mais, si on les considère comme "personnage", les trois sont susceptibles de faire exactement la même chose... Même si leur aptitude à le faire peut être différente.

Si tu veux partir sur une idée d'héritage, ce serait plutôt une classe "race", et encore... Même du point de vue des race, ce ne sont que les données lues ou écrites qui sont susceptibles de changer (données "d'affichage", valeurs par défaut, liste des sorts et des capacités qu'ils peuvent acquérir, amement "de base" et particulier...)

Au final, ce serait donc plutôt ces éléments qui devraient partir sous des formes polymorphiques, et qui devraient, au pire, vérifier lors de la tentative d'équipement/d'apprentissage si le personnage est de la bonne race :P, et tout cela peut donc simplement se faire en maintenant une simple énumération dans le personnage ;)

Ben oui je pensais à ce qu'explique koala.

Mais c'est peut-être abusif de dire que c'est une erreur, c'est plus que ce n'est peut-être pas le plus habile.

MAT.

Mon projet n'est pas autant optimiste, je désire juste avoir deux groupes de personnages, les armes ce ne sera pas pour tout de suite(peut-être un futur projet, je suis surtout en phase d'apprentissage), chacun d'entre eux pouvant avoir une race et un métier différent.

Donc la classe personnage ne serait pas utile, mais plutôt une classe race comportant par exemple 3 constructeurs différents pour chaque race si j'arrive à suivre le raisonnement.

Mais dans le cas où je veut gérer des métiers en plus, par exemple mage guerrier et prêtre, comment puis-je m'y prendre, créer une classe métier du même style que race comportant 3 constructeurs, mais alors comment associer à un personnage sa race puis sont métier.

Si les métiers changent beaucoup le personnage, je pense qu'une bonne solution serait de dériver une classe de Nain par exemple, et de transformer ton instance Nain en Nain_Magicien par exemple quand il change de métier.

Si il y a des caractère commun entre un Nain_Magicien et un Elfe_Magicien, tu peux même utiliser l'héritage multiple:

Code:

---

1 2 3 4

class Nain_Magicien: public Nain, public Magicien { ... };

---

Citation:

---

Envoyé par Mat007

Ben oui je pensais à ce qu'explique koala.

Mais c'est peut-être abusif de dire que c'est une erreur, c'est plus que ce n'est peut-être pas le plus habile.

MAT.

---

Tu remarquera que je ne parlais absolument pas d'erreur, je me posais la question de savoir si c'était opportun :D

Citation:

---

Envoyé par mathrb

Mon projet n'est pas autant optimiste, je désire juste avoir deux groupes de personnages, les armes ce ne sera pas pour tout de suite(peut-être un futur projet, je suis surtout en phase d'apprentissage), chacun d'entre eux pouvant avoir une race et un métier différent.

Donc la classe personnage ne serait pas utile, mais plutôt une classe race comportant par exemple 3 constructeurs différents pour chaque race si j'arrive à suivre le raisonnement.

---

En fait, ce serait même plutot de gérer "simplement" la race sous la forme d'une énumération (que le perso puisse dire "je suis un humain", "je suis un elfe" ou "je suis un nain")...

Citation:

---

Mais dans le cas où je veut gérer des métiers en plus, par exemple mage guerrier et prêtre, comment puis-je m'y prendre, créer une classe métier du même style que race comportant 3 constructeurs, mais alors comment associer à un personnage sa race puis sont métier.

---

Ben, le métier va simplement demander au personnage "es-tu un nain/ un elfe / un humain :question:", et, selon la réponse, acceptera ou non d'être affecté au personnage ;)

Ou, si tu préfère, une fois que tu a la liste de tes métiers, le personnage demande à la liste "puis-je devenir <telle chose> en sachant que je suis <tel type de perso>:question:"

Citation:

---

Envoyé par coyotte507

Si les métiers changent beaucoup le personnage, je pense qu'une bonne solution serait de dériver une classe de Nain par exemple, et de transformer ton instance Nain en Nain_Magicien par exemple quand il change de métier.

Si il y a des caractère commun entre un Nain_Magicien et un Elfe_Magicien, tu peux même utiliser l'héritage multiple:

Code:

---

1 2 3 4

class Nain_Magicien: public Nain, public Elfe_Magicien { ... };

---

---

je verrais plutot

Code:

---

1 2 3 4

class Nain_Magicien: public Nain, public Magicien {   };

---

parce que je vois mal un nain avoir des capacités elfiques :P:roll:

Dans le cadre d'un projet nous avions fait comme ça

MovingObject : Object

CreatureObject : MovingObject

PlayerObject : CreatureObject


Et les races etaient des enums (vu que toute créature en "possède" une).

Code:

---

1 2 3 4

class Nain_Magicien: public Nain, public Magicien {   };

---

Mais avec ça je garde mes classes Nain,humains.. plus les classes Métier
Ce qui me fait par la suite un nombre de classe de type nb_classe_race*nb_classe_métier , ça fait un peu beaucoup non? ou alors c'est normal?
Je vais vous exposez ce que je cherche au final
par exemple : MonGroupeA.MonPerso(i).attaque(MonGroupeB.MonPerso(j))
Bon, cela va vous faire hurler, mais je viens d'un langage appellé vb.net un tant soit peu "laxiste",
Avec toujours MonPerso qui peut être de n'importe qu'elle métier ou race

Merci beaucoup à vous

Citation:

---

Envoyé par koala01

je verrais plutot

Code:

---

1 2 3 4

class Nain_Magicien: public Nain, public Magicien {   };

---

parce que je vois mal un nain avoir des capacités elfiques :P:roll:

---

effectivement

Citation:

---

MonGroupeA.MonPerso(i).attaque(MonGroupeB.MonPerso(j))

---

Tu peux faire ca, vu que ton Nain_Magicien dérive deux fois de Personnage.

Citation:

---

Envoyé par mathrb

Code:

---

1 2 3 4

class Nain_Magicien: public Nain, public Magicien {   };

---

Mais avec ça je garde mes classes Nain,humains.. plus les classes Métier
Ce qui me fait par la suite un nombre de classe de type nb_classe_race*nb_classe_métier , ça fait un peu beaucoup non? ou alors c'est normal?
Je vais vous exposez ce que je cherche au final
par exemple : MonGroupeA.MonPerso(i).attaque(MonGroupeB.MonPerso(j))
Bon, cela va vous faire hurler, mais je viens d'un langage appellé vb.net un tant soit peu "laxiste",
Avec toujours MonPerso qui peut être de n'importe qu'elle métier ou race

Merci beaucoup à vous

---

En fait, personnellement, je verrais bien plutot un truc dans le genre de

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

class Job { public: /*...*/ /*vérifie si le perso dispose des caractéristiques pour apprendre le   * métier   */ virtual bool InRange(const Perso &)= 0; /* applique les modifications entrainées par le métier   */ virtual void ApplyModifier(Perso * tochange) = 0; [EDIT]/* < Ajout >*/ private: std::vector<Skill* > skills; /* < /Ajout > */ [/EDIT] }; class Warrior: public Job { }; class Wizzard: public Job {   }; class Hunter: public Job {   }; /* + les variation concernant la race : NainWarrior: public Warrior etc */

---

où chaque classe instanciable redéfini les méthodes InRange et ApplyModifier

et tu aurais une "simple" liste (ou un tableau ou ...) de pointeurs sur Job dans ton Perso sous une forme proche de

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

class Perso { public: /*...*/ bool IsHuman() const; bool IsElfic() const; bool IsNain() const; /* les autres test concernant la race */ void LearnJob(Job*); bool IsWizzard() const; /*les autres tests concernant le metier */ private: std::list<Job*> jobs; enum { rHuman, rElfic, rNain, /*...*/ } race; };

---

avec LearnJob sous une forme proche de

Code:

---

1 2 3 4 5 6 7 8

void LearnJob(Job *tolearn) { if(tolearn->InRange(*this)) { tolearn->ApplyModifier(); jobs.push_back(tolearn()); } }

---

et IsWizzard et autres similaires sous une forme proche de

Code:

---

1 2 3 4 5 6 7 8 9

bool IsWizzar() const { for(std::list<Job*>::const_iterator it=jobs.begin(); it!=jobs.end;it++) { if( dynamic_cast<Wizzard*>((*it))) return true; } return false; }

---

Citation:

---

Envoyé par mathrb

Code:

---

1 2 3 4

class Nain_Magicien: public Nain, public Magicien {   };

---

Mais avec ça je garde mes classes Nain,humains.. plus les classes Métier
Ce qui me fait par la suite un nombre de classe de type nb_classe_race*nb_classe_métier , ça fait un peu beaucoup non? ou alors c'est normal?

---

Sinon, tu as l'approche par classes de politique :

Code:

---

1 2 3 4 5 6 7 8 9 10

template < PolitiqueRace, PolitiqueClasse > class Personnage : public PolitiqueRace, public PolitiqueClasse {   };   Personnage<Nain,Magicien> Hector;

---

Bon,finalement je suis partis sur ce modèle
une classe race avec trois filles(humains...), race ayant une méthode virtual attaque, des points de vie et de dégats intialisés dans la classe fille
une classe métier avec trois filles(guerrier...), ayant une attaque spéciale sur un personnage
et une classe personnage héritant de race et métier
De là plusieurs questions se posent, puis-je faire ceci:
dans la définition de ma méthode attaque : virtual void attaque(personnage &cible) afin ensuite d'atteindre les points de vie du personnage provenant de l'héritage de la classe race

Je ne vois pas l'intérêt pour personnage de dériver de métier et de race. Par contre, qu'un personnage possède un métier et une race (ou plusieurs) me semble plus judicieux. Ne serait-ce que parce qu'il pourra en changer en cours de jeu.

De même, si la race ou le métier se limitent uniquement à des caractéristiques toutes les mêmes mais dont uniquement les valeurs changent, et non pas à des comportement différents, je ne vois pas non plus l'intérêt de l'héritage des métiers et races. Et si ce n'est pas le cas, si le fonctionnement (et pas uniquement le nombre) des points de vie par exemple est différent en fonction de la race ou du métier, et bien j'ai envie de dire qu'il y a un problème dans le système de jeu.

Là où je peux voir un intérêt à l'héritage, c'est par exemple pour définir les stratégies de combat des différents personnages. L'un pourra être un fonceur, l'autre un nuker, l'autre un tank, l'autre un buffer. Là on a des comportements différents.