Discussion :

[b Oo]

Bonjour à tous,
je voudrais avoir votre avis sur la conception d'un projet :
Les fichiers :

• l'énoncé du projet
• le diagramme de classes
• le code source

Pour l'histoire, il s'agit d'un petit projet donné en L3 Info. Les auteurs du sujet sont donnés sur le pdf.

Pour ce à qui n'ont pas voulu lire le pdf
"Le but du projet est de modéliser un mode animal, c’est à dire voir les intéractions entre les trois
éléments du monde : les carnivores mangent les herbivores et les herbivores mangent l’herbe. Pour
construire un monde animal, il est nécessaire de savoir sur quel continent on se trouve. En Amérique,
les carnivores sont les loups et les herbivores les bisons, tandis qu’en Afrique ce sont les lions et les
girafes."

La classe MondeAnimal

La classe MondeAnimal est la classe principale de notre simulation. Nous déclarons une instance de cette classe en lui passant le continent sur lequel nous voulons réaliser la simulation, et nous appelons ensuite la méthode run.
La classe MondeAnimal contient une grille de pointeurs sur des FauneFlore. (FauneFlore est une interface pour les classes Animal et Vegetal, nous la décrivons en détail dans le paragraphe suivant).


Creator et Runner :

Nous avons également défini deux autres classes dans le même fichier, car celles-ci sont des outils nécessaires au fonctionnement de MondeAnimal.
La première est la classe Runner. Il s’agit d’un foncteur qui est utilisé dans la méthode run de MondeAnimal. Nous avons créé cette classe pour pouvoir utiliser l’algorithme for_each de la STL dans la méthode run.
Il permet d’appeler pour chaque case la grille la méthode run. Le constructeur prend en paramètre un MondeAnimal par référence car la méthode run d’un FauneFlore modifie le MondeAnimal.

Le deuxième foncteur, Creator, permet de créer des FauneFlore en appelant les méthodes de fabrication du Continent passé en paramètre dans le constructeur de Creator.
Creator contient donc des pointeurs de méthodes sur la classe Continent. Cela nous permet de remplir la grille aléatoirement. Creator est donc lui aussi un foncteur qui renvoie un pointeur sur un FauneFlore.
La grille est alors simplement remplie avec l’algorithme generate de la STL, et le Creator passé en paramètre.
A noter la syntaxe de la déclaration d’un pointeur sur une méthode :
typedef FauneFlore*(Continent::* FauneFloreCreator)()const;
et l’appel de la méthode :
(continent_.*creator_[random_])();
Avec creator_ qui contient l’adresse des méthodes de fabrication.
Les méthodes de la classe MondeAnimal sont les suivantes :

• void affiche() const; permet d’afficher la grille, le nom des espèces est centré
• void run(const size_t nbIter = 1); permet de lancer la simulation nbIter fois
• void supprime(const size_t cle); supprime l’élément à l’indice clé, un Animal appelle cette méthode lorsqu’il mange quelque chose
• inline void setEspace(const size_t espace); défini le nombre de caractères sur lequel nous affichons l’espèce d’un animal, il faut que ce nombre soit supérieur à la longueur maximale des espèces
• inline size_t getTaille() const; renvoie la taille d’un côté de la grille
• inline FauneFlore * operator[](const size_t cle); renvoie le FauneFlore d’indice cle
• inline const FauneFlore * operator[](const size_t cle) const; renvoie le FauneFlore d’indice cle
• inline void echange(const size_t pos1, const size_t pos2); échange le contenu des cases en appelant swap de la STL, nécessaire pour le déplacement des animaux

La classe FauneFlore

FauneFlore est la classe mère de tous les animaux et végétaux. Elle nous permet d’avoir un conteneur de pointeurs sur la classe mère, et donc d’appeler les méthodes des « vraies classes » par le polymorphisme.

getArticle, getType, getName sont des méthodes qui permettent respectivement de retourner l’article (ie : le, la, une), le type (ie : herbivore, carnivore, vegetal), et le nom de l’espèce (ie : lion, loup, …).
findCaseVide permet de trouver s’il existe une case vide autour de l’animal, et find permet de trouver de la nourriture se trouve dans une case voisine. Pour find, nous passons le type (ie : vegetal, carnivore, herbivore) en paramètre.
Nous avons bien sûr la méthode run qui ne fait rien pour le Vegetal. Pour Carnivore et Herbivore, elle teste si l’animal peut manger, si oui, l’animal mange, sinon il se déplace (s’il peut).



Il n'y a pas les classes Continent, Amerique, Afrique car elles ne sont pas très compliquées. TLogfile permet juste de sauvegarder dans un fichier les différents évènements.



Les problèmes de notre conception sont :

1. la duplication de la méthode run, en effet juste une chose varie entre les 2
2. la méthode type() et getType() qui sont vraiment pas top

1. La duplication de la méthode run a été obligée car nous pour un herbivore nous cherchons de l'herbe autour, alors que pour un carnivore nous cherchons un herbivore. A part ceci c'est le même code.

2. Nous avons utiliser la méthode getType pour forcer les classes filles a implémenter cette méthode et pour faire des "méthodes virtuelles statiques".
Nous utilisons type pour trouver un animal avec la méthode find.

J'aimerais donc savoir si nous aurions pu éviter les deux points précédents. Le premier peut être résolu de la maniére suivante :
j'implémente la méthode run dans Animal, et je crée un méthode regime virtuelle pure qui dit ce qu'un Animal mange et find appelle cette méthode.
Il y a peut-être mieux, non ?

Je voudrais également savoir, imaginons que j'ai 5 000 animaux. Est-ce qu'il pourrait-être intéressant de faire un pattern stratégie pour la méthode run (ie le comportement d'un animal) ?

N'hesiter pas a faire des remarques sur la conception même si elle a été beaucoup guidée.

Merci d'avance.

[loufoque]

La classe MondeAnimal contient une grille de pointeurs sur des FauneFlore. (FauneFlore est une interface pour les classes Animal et Vegetal, nous la décrivons en détail dans le paragraphe suivant).

Pourquoi des pointeurs ? T'alloues dynamiquement des types dérivés pour pouvoir stocker ça de manière uniforme ? (ce qui d'ailleurs n'est pas nécessaire)
Dans ce cas, tu n'as pas des problèmes d'exception safety ?
Tu n'as d'ailleurs pas vraiment précisé qui avait la charge de gérer les différentes ressources.

La première est la classe Runner. Il s’agit d’un foncteur qui est utilisé dans la méthode run de MondeAnimal. Nous avons créé cette classe pour pouvoir utiliser l’algorithme for_each de la STL dans la méthode run.

Un simple bind aurait suffit.

Il permet d’appeler pour chaque case la grille la méthode run. Le constructeur prend en paramètre un MondeAnimal par référence car la méthode run d’un FauneFlore modifie le MondeAnimal.

Le monde ne devrait-il pas être disponible sous forme de singleton ou autre truc du genre plutôt ?

Le deuxième foncteur, Creator, permet de créer des FauneFlore en appelant les méthodes de fabrication du Continent passé en paramètre dans le constructeur de Creator.
Creator contient donc des pointeurs de méthodes sur la classe Continent. Cela nous permet de remplir la grille aléatoirement. Creator est donc lui aussi un foncteur qui renvoie un pointeur sur un FauneFlore.
La grille est alors simplement remplie avec l’algorithme generate de la STL, et le Creator passé en paramètre.
A noter la syntaxe de la déclaration d’un pointeur sur une méthode :
typedef FauneFlore*(Continent::* FauneFloreCreator)()const;
et l’appel de la méthode :
(continent_.*creator_[random_])();
Avec creator_ qui contient l’adresse des méthodes de fabrication.

Mouais, ça me parait pas top.

void affiche() const = 0; permet d’afficher la grille, le nom des espèces est centré

Pourquoi la fonction est pure ?
Il y a une histoire d'héritage de monde ?

inline void setEspace(const size_t espace); défini le nombre de caractères sur lequel nous affichons l’espèce d’un animal, il faut que ce nombre soit supérieur à la longueur maximale des espèces

Quel intérêt de limiter ça ? Utilise std::string.

inline FauneFlore * operator[](const size_t cle); renvoie le FauneFlore d’indice cle
inline const FauneFlore * operator[](const size_t cle) const; renvoie le FauneFlore d’indice cle

Ne serait-il pas mieux de retourner des références ?

Elle nous permet d’avoir un conteneur de pointeurs sur la classe mère, et donc d’appeler les méthodes des « vraies classes » par le polymorphisme.

Pourquoi la classe contient des pointeurs ?

getArticle, getType, getName sont des méthodes qui permettent respectivement de retourner l’article (ie : le, la, une), le type (ie : herbivore, carnivore, vegetal), et le nom de l’espèce (ie : lion, loup, …).

getType est déjà fourni par le RTTI.

Je croyais aussi qu'une FauneFlore avait une fonction membre run ?

[b Oo]

Merci loufoque de t'être penché sur le problème.

Pourquoi des pointeurs ? T'alloues dynamiquement des types dérivés pour pouvoir stocker ça de manière uniforme ? (ce qui d'ailleurs n'est pas nécessaire)
Dans ce cas, tu n'as pas des problèmes d'exception safety ?
Tu n'as d'ailleurs pas vraiment précisé qui avait la charge de gérer les différentes ressources.

MondeAnimal crée les objets et les detruits. Donc, les ressources sont seulement gérées par MondeAnimal. Pourquoi des pointeurs et non des objets ?
Lorsqu'un Carnivore mange un Herbivore je le détruis.

Un simple bind aurait suffit.

Non car :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
void Runner::operator()(FauneFlore * fauneFlore)
{
    if (fauneFlore != 0)
        fauneFlore->run(monde_, indice_);
    ++indice_;
    indice_ %= taille_;
}

monde_ est la référence sur le MondeAnimal et indice, c'est l'indice sur la case de la grille.

Le monde ne devrait-il pas être disponible sous forme de singleton ou autre truc du genre plutôt ?

Non je ne pense pas, nous pouvons lancer des simulations sur différents mondes. Sinon je pourrais limiter à 5 le nombre d'instances pour les 5 continents et là ça rejoint ce que tu as dis.

Quel intérêt de limiter ça ? Utilise std::string.

Tu as pensé que je limitais le nombre de caractères de la chaine ?
Non, en fait c'est pour le setw. Cela me permet d'avoir un affichage centré et pour cela je dois avoir une valeur plus grande dans le setw que la longueur max d'une chaine.

Pourquoi la classe contient des pointeurs ?

Non pas la classe FauneFlore mais MondeAnimal oui.
C'est juste pour dire pourquoi j'ai rajouter une classe FauneFlore.

getType est déjà fourni par le RTTI.
Je croyais aussi qu'une FauneFlore avait une fonction membre run ?

Oui, on est d'accord, je ne teste pas avec le type pour savoir quel méthode j'appelle.
Mais si j'ai une grille 2x2 :
-------------
Lion | Girafe |
-------------
rien | Herbe |
-------------
Je voudrais que Girafe avec la méthode find cherche de l'herbe et si elle en trouve la mange.
De même le Lion avec la méthode find cherche une Girafe et s'il en trouve la mange.
Cela sans changer la méthode find définit dans la classe Animal.
Sinon je pourrais faire dynamic_cast à la place de mon getType pour savoir si c'est le bon truc que j'attends.
Car là je ne vois pas comment le RTTI peut m'aider.

Je mets le lien dans le 1er post vers le code source dans quelques minutes.

[loufoque]

dynamic_cast est implémenté grâce au RTTI.

[b Oo]

Autant pour moi.
Si je veux éviter un dynamic_cast il suffit que je définisse une méthode qui fait ce que j'attends ?
C'est plus "beau" de faire une nouvelle méthode qu'un dynamic_cast non ?

Sinon pour Creator tu n'aimais pas trop ça, tu vois quelque chose d'autre ?

Merci encore.

[JolyLoic]

Autant pour moi.
Si je veux éviter un dynamic_cast il suffit que je définisse une méthode qui fait ce que j'attends ?
C'est plus "beau" de faire une nouvelle méthode qu'un dynamic_cast non ?

Pourquoi serait-ce plus beau ?

Ce qui est "moche" dans le dynamic_cast, ce n'est pas le dynamic_cast, c'est de devoir faire un traitement spécifique à une classe dérivée particulière, sans pouvoir encapsuler ce traitement dans une fonction virtuelle de cette classe. A partir du moment où tu as décidé que c'est ce que tu voulais faire, autant utiliser un outil tout fait pour le faire.

D'autant plus que dynamic_cast a l'avantage de marcher avec des hiérarchies sur plus de deux niveaux, ce qui n'était pas le cas de la plupart des fonctions bricolées pour le remplacer que j'ai pu rencontrer. J'entends pas là, si C dérive de B qui dérive de A, tu as un A* qui pointe sur un objet de type C. Un dynamic_cast en B* de ce pointeur sera un succès, ce qui est une bonne chose. Un test de type monA->getType()==B::GetTypeName() échouera.

Un cas où je pourrait voir l'intérêt de faire ce genre de chose, c'est si le type n'est pas directement lié à la hiérarchie de classe. Par exemple, dans une hiérarchie mammifères/oiseaux/reptiles, tu pourrait être tenté d'utiliser le RTTI pour implémenter une fonction indiquant si un animal pond des oeufs. Jusqu'au jour où tu rencontres un ornithorynque.

[b Oo]

Salut,
non je ne veux pas "bricoler" une méthode, je pensais à une méthode virtuelle. Je n'ai pas été très clair, il faut croire.
Je ne vois pas d'ailleurs comment une méthode non virtuelle pourrait arranger mon problème ici.
Je demandais s'il vallait mieux que je crée une méthode virtuelle ou s'il était mieux de rester avec dynamic_cast.
Le choix de la méthode virtuelle est surement meilleur si la méthode s'applique à toute ma hiérarchie, non ?

[JolyLoic]

Le bricolage auquel je pense fait lui aussi appel à une fonction virtuelle... Mais montre moi ce que tu as en tête. En particulier, est-ce que ça passe le test des hiérarchies à plus de 2 étages ?

[b Oo]

Salut,
je suis d'accord avec toi que getType n'est pas une solution très élégante.
getType() ne me permet pas de savoir quel est exactement le type de la classe, mais il permet de me dire si un FauneFlore est un herbivore ou un carnivore ou un végétal.
Pourquoi j'ai besoin de savoir cela, car un carnivore mange un herbivore et un herbivore mange un végétal. Et ca je ne sais pas comment le traduire sans un getType.
J'ai bien fait un code sans getType mais celui-ci n'est pas très bien non plus.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
template <class Nourriture>
size_t Animal::find(const MondeAnimal & mondeAnimal, const size_t pos, const Nourriture * n) const
{
    delete n; // car on cree un objet juste pour le template
    size_t taille = mondeAnimal.getTaille();
 
    // on recherche l'element a gauche de pos
    size_t indiceElt = pos-1;
    // si on est pas sur un bord
    if (pos > 0 && (pos % taille) != 0)
        // renvoie si 0 si pas le bon type et si le pointeur est deja a 0
        if(dynamic_cast<const Nourriture *>(mondeAnimal[indiceElt]) != 0) 
            return indiceElt;
 
    // on recherche l'element a droite de pos
    indiceElt = pos+1;
    // si on est pas sur un bord
    if (indiceElt < taille*taille && (indiceElt % taille) != 0)
        if(dynamic_cast<const Nourriture *>(mondeAnimal[indiceElt]) != 0) 
            return  indiceElt;
 
 
    // on recherche l'element en bas de pos
    indiceElt = pos-taille;
    if (pos >= taille)
           if(dynamic_cast<const Nourriture *>(mondeAnimal[indiceElt]) != 0) 
                return indiceElt;
 
 
    // on recherche l'element en haut de pos
    indiceElt = pos+taille;
    if (indiceElt < taille*taille)
        if(dynamic_cast<const Nourriture *>(mondeAnimal[indiceElt]) != 0) 
            return indiceElt;
 
    return pos;
}
 
 
void Animal::run(MondeAnimal & mondeAnimal, const size_t pos) const
{
    size_t cle = find(mondeAnimal, pos, nourriture());
    if (cle != pos)
    {
        mange(mondeAnimal[cle]);
        mondeAnimal.supprime(cle);
    }
    else
    {
	cle = findCaseVide(mondeAnimal, pos);
	if (cle != pos)
	{
	    mondeAnimal.echange(pos, cle);
	    ostringstream entier1;
	    ostringstream entier2;
	    entier1 << pos+1;
	    string chaine = this->getName() + " se deplace de la case ";
	    chaine += entier1.str();
	    chaine += " a la case ";
	    entier2 << cle+1;
	    chaine +=  entier2.str();
	    TLogFile::getInstance().ecrire(chaine);
	}
	else
	{
	    string chaine = this->getName() + " ne peut pas bouger";
	    TLogFile::getInstance().ecrire(chaine);
	}
    }	    
}

nourriture() est une méthode qui crée un objet dynamique sur la nourriture d'un animal

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Vegetal * Herbivore::nourriture() const
{
    return new Vegetal(); 
}

je me sert également du fait que l'on peut modifier le type de retour pour une hiérarchie :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
virtual FauneFlore * FauneFlore::nourriture() const
{ 
   return 0;
}
Herbivore * Carnivore::nourriture() const
{
    return new Herbivore(); 
}

En fait l'objet ne me sert à rien ici, c'est juste pour pouvoir faire un dynamic_cast du type de mon objet et car je ne peux passer directement un objet dans le paramètre de mon template.

Le problème avec cette méthode est le delete dans ma méthode find et je dois aussi rendre instanciable mes classes Herbivore et Végétal.

[loufoque]

Déjà y'a un delete ailleurs que dans un destructeur.
C'est mal parti.

[Patriarch24]

je suis d'accord avec toi que getType n'est pas une solution très élégante.
getType() ne me permet pas de savoir quel est exactement le type de la classe, mais il permet de me dire si un FauneFlore est un herbivore ou un carnivore ou un végétal.
Pourquoi j'ai besoin de savoir cela, car un carnivore mange un herbivore et un herbivore mange un végétal. Et ca je ne sais pas comment le traduire sans un getType.
J'ai bien fait un code sans getType mais celui-ci n'est pas très bien non plus.

Double aiguillage ? Pattern "visitor" !

[bolhrak]

Déjà y'a un delete ailleurs que dans un destructeur.
C'est mal parti.

Bon ma question va être un peu HS, désolé, mais comment peux tu garantir des delete uniquement dans des destructeurs ?

Par exemple si j'ai une classe DocumentManager, qui contient une liste de documents, il faut bien qu'il les détruise à chaque fois un document est fermé non ? Ou bien tu passes systématiquement par des handlers ?

[Laurent Gomila]

Bon ma question va être un peu HS, désolé, mais comment peux tu garantir des delete uniquement dans des destructeurs ?

Là par exemple tu peux prendre un std::auto_ptr en paramètre, plutôt qu'un pointeur brut.
Tu pourrais aussi ne rien passer du tout et spécifier le paramètre template explicitement.

Voir la FAQ pour plus de détails concernant les pointeurs intelligents et le RAII.

[loufoque]

Bon ma question va être un peu HS, désolé, mais comment peux tu garantir des delete uniquement dans des destructeurs ?

Tu peux toujours lire ça que j'ai écrit y'a pas longtemps sur usenet et qui apparemment n'a intéressé personne.
http://groups.google.com/group/comp....48fe777747e426

[b Oo]

Le problème avec cette méthode est le delete dans ma méthode find et je dois aussi rendre instanciable mes classes Herbivore et Végétal.

Déjà y'a un delete ailleurs que dans un destructeur.
C'est mal parti.

Pour eviter le delete je peux renvoyer un auto_ptr ou sinon il faut que j'encapsule mon objet dans une classe.
Si j'utilise un auto_ptr, il sera détruit à la fin de la fonction, c'est bien çà ?

Double aiguillage ? Pattern "visitor" !

Il faudrait que je fasse un visiteurType qui me renvoie le type de l'objet ?

Merci encore.

[Laurent Gomila]

Si j'utilise un auto_ptr, il sera détruit à la fin de la fonction, c'est bien çà ?

Oui.

[bolhrak]

@Laurent Gomilla : je connais déjà ces techniques, ma questino portait plus de manière générale, mais tu y réponds en grande partie Disons que mon problème est que j'utilise quand même beaucoup les pointeurs, et que pas mal de commentaires sur ce forum me font me poser des questions.

@Loufoque : merci pour le lien :p Malheureusement je ne connais pas très bien C++/CLI, je vais donc me renseigner sur le sujet avant, mais j'ai quand même l'impression que cela va bien plus loin que la question que je me pose (en même temps c'est pas plus mal me permettra de découvrir de nouveaux trucs )

[Laurent Gomila]

@Laurent Gomila : je connais déjà ces techniques, ma questino portait plus de manière générale, mais tu y réponds en grande partie Disons que mon problème est que j'utilise quand même beaucoup les pointeurs, et que pas mal de commentaires sur ce forum me font me poser des questions.

C'est pour ça que je t'ai orienté vers les pointeurs intelligents et le RAII. Normalement avec la FAQ tu devrais avoir un bon point de départ sur ces 2 concepts.

[loufoque]

@Loufoque : merci pour le lien :p Malheureusement je ne connais pas très bien C++/CLI

Mon message ne parle pas de C++/CLI.
Mais bon apparemment le problème vient de mon lien, j'avais voulu pointer sur un message en particulier mais apparemment ça pointe que vers le début du fil.
Ce lien semble fonctionner.

[JolyLoic]

Personellement, j'ai du C++/CLI la plus mauvaise expérience qui me semble possible de l'introduction d'un Garbage Collector en C++. Lier l'utilisation ou pas du GC au système de type, bien qu'attrayant au premier abord, ne marche pas vraiment, puisque le choix d'avoir une donnée partagée n'est pas du ressort de la donnée elle même, mais de l'usage que l'on soihaite en faire.

Dans ce sens, je préfère largement la proposition de Boem, qui a l'avantage d'être globalement compatible avec les programmes actuels raisonnables. Elle peut rendre correct des programmes qui ne le sont pas, mais ne peux pas rendre incorrecte des programmes raisonnables qui le sont (avec la bonne définition du mot raisonnable ). Je manque d'expérience avec ce GC, mais j'ai bien envie d'essayr un de ces jours.

Donc quand tu (si j'ai bien suivi, c'est toi Mathias Gaunard, l'auteur de l'article en question) proposes que le GC soit une fonctionnalité séparée, comment proposes-tu que cette séparation ait lieu ?