Discussion :

[Maerlyn]

Salut à tous,

Voici un petit problème qui me tracasse depuis quelques jours.

J'ai (notemment) deux classes : Species et Individual. Je m'interesse à la relation entre les deux. Jusqu'à maintenant j'étais parti sur une agrégation (un individu faisant parti d'une espece). Les individus de la même espece étaient donc stockés dans une liste chainées avec un pointeur sur le premier element dans la classe Species. Cela fonctionnait parfaitement jusqu'au moment où j'ai eut à manipuler les individus indépendemment de leur classe.
Arrive le moment où j'ai besoin de savoir à quelle espece appartient tel individu...
Seulement une agrégation ne permet pas de "remonter". J'ai donc voulu stocker dans Individual un pointeur vers l'espece à laquel il appartient. Mais cela représente une sorte d'agrégation à double sens, et forcement ça ne compile pas

J'ai donc deux solutions sous la main. Mais avant d'aller plus loin je voudrai l'avis de personnes plus expérimentées que moi !

- La méthode bourrine : Je stocke (lors de sa création) une chaine de caractère dans individus correspondant au nom de l'espece à laquelle il appartient. Etant donné que l'un des attribus de Species est son nom, il ne me reste plus qu'à faire des strcmp() pour retrouver celle qui correspond. Ca me parait quelque peu "crado" quand même...

- L'héritage. Je me pose de plus en plus de question sur l'héritage ici. D'un point de vue de code pur, si je ne me trompe pas l'héritage me permetrai de "remonter" et ainsi partant d'un pointeur sur un individu, je devrai pouvoir retrouver à quelle espece il appartient. Seulement est-ce bien approprié ? Un individu n'est pas une espece. (par contre une instance d'individu est bien une instance d'espece : Snoopy est bien un chien). Est ce que cela ne risque pas de me jouer des tours soit dans l'implementation de l'héritage en lui-même, soit par la suite ?

Voilà, je suis un peu perdu là... Tout conseil est le bienvenu !

D'avance, grand merci

[poukill]

Hum sympa ton problème !
Tout d'abord, c'est très bien de te poser le problème comme ça.

Ensuite, je serai toi, je ne ferai pas d'héritage. Ce serait à mon avis une erreur, il faut attention au raccourci "est un"...
Si tu as une classe PARIS (pour une étude quelconque) et une classe VILLE, il ne faut pas faire hériter PARIS de VILLE. Pourtant Paris est une VILLE, mais l'héritage ce n'est pas ça.

Si tu as une classe ESPECE, alors CARNIVORE serait une descendante, de même que HERBIVORE... Et peut-être même OMNIVORE hériterai des deux classes ci-dessus...


Dans ton cas, si j'ai bien compris, je ferai une aggrégation comme tu as fait.
Pourquoi ne pas stocker tout simplement une liste : std::list<Individu>.
Dans la classe Individu, tu passes une instance d'ESPECE dans le constructeur que tu stockes sous forme de référence.
Pourquoi pas un pointeur? Le pointeur tu l'utilises quand tu pointes vers une classe abstraite, car c'est alors impossible de le faire avec une référence.
Du coup, chaque Individu possède une référence à son espèce, et à donc accès à ses champs publics sans problèmes...

Ceci ne pose AUCUNS problèmes à la compilation !

[Alp]

+1. Je ferais pareil.
L'héritage est une solution utilisée trop souvent à tord, comme raccourci.
Je te conseille "Mieux programmer en C++" de Herb Sutter (http://www4.fnac.com/shelf/article.aspx?PRID=1135127) qui traite dans un passage du livre de ces relations.

[poukill]

Comme bouquin sur de la conception, tu as aussi :
"Conception et Programmation orientées objet", Bertand Meyer. il traite de tout sans se focaliser sur un language précis.

[nicroman]

C'est une bonne solution...

En même temps, la relation entre "Individu" et "Espece" est: "est un instance de". Certainement pas "est un" (si quelqu'un veut travailler avec une espece, on ne peut, logiquement, pas lui passer un 'individu').

Plusieurs solutions sont alors dispobibles: la solution de poukill est très bonne.
Une autre solution, par exemple, qui force à avoir une espece définie:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
class Individu
{
    virtual const Specy& GetSpecy() const = 0;
};
 
class Human: public Individu
{
    static Specy  species;
 
    virtual const Specy& GetSpecy()
    { return humains; }
};

[loufoque]

- La méthode bourrine : Je stocke (lors de sa création) une chaine de caractère dans individus correspondant au nom de l'espece à laquelle il appartient. Etant donné que l'un des attribus de Species est son nom, il ne me reste plus qu'à faire des strcmp() pour retrouver celle qui correspond. Ca me parait quelque peu "crado" quand même...

Un entier suffit amplement.
Tu peux mettre en place ce genre de technique de manière typesafe avec boost.variant.

[Maerlyn]

Bon tout d'abord, merci à tous pour toutes ces informations !!

A propos des bouquins, ce n'est malheureusement pas une option que je peux envisager. Je suis étudiant erasmus en Norvège. Autrement dit obtenir un livre en français, c'est forcement par commande sur internet, ce qui non seulement me demanderai du temps mais aussi me couterai bonbon (deux ressources dont je manque cruellement ). Néanmoins, je note les references ! Je passerai à la fnac à mon retour au pays du vin et du fromage En attendant, je devrai me contenter de ce que je peux trouver sur le net.

Je vais reprendre vos suggestions une à une. Et comme j'aime bien faire les choses à l'envers, on va commencer par Loufoque (et en plus ça colle avec ton pseudo, )!

Un entier suffit amplement.
Tu peux mettre en place ce genre de technique de manière typesafe avec boost.variant.

En effet, j'y ai également pensé. Si je parle de chaines de caractère c'est parceque j'ai déjà stocké le nom de l'espece dans la classe Species. Mais oui, si je m'oriente vers cette solution, je ferai surement ça avec des entiers. Quoi qu'il en soit, je garde cette idée comme solution de secours uniquement. Je reste persuadé que ce n'est pas bien propre et qu'il y a mieux à faire.

Pour répondre à Nicroman, déjà il me faut avouer que je suis loin d'être un pro en C++. Je serai même plutôt un débutant. J'ai donc encore besoin d'un peu de temps pour bien comprendre en détail le bout de code que tu as posté. Mais quoi qu'il en soit, cette solution risque de ne pas me convenir étant donner que ça me force à coder en dur chaque espece. Et ceci n'est pas acceptable dans le cadre de mon projet. Néanmoins, je vais essayer de piger ton truc, ne serait-ce que par curiosité.

Enfin Poukill,

Ta solution me semble la plus adéquate. Maintenant j'émets quelques réserves (et oui je suis un chiant de nature ). Quand tu parles de stocker les individus dans une std::list, ça revient à ce que j'ai fais si je ne trompe pas. J'ai créer une liste chainée (chaque individu a un pointeur vers le suivant) et je l'ai stockée dans Species (un pointeur vers le premier individu). Bon ne connaissant pas l'existance de std::list, j'ai un peu réinventé la roue et je jete un oeil en ce moment à cette librairie. Mais quand tu dis :

Ceci ne pose AUCUNS problèmes à la compilation !

ce n'est pas que je doute de tes compétences en programmation, mais plutot j'aimerai bien savoir pourquoi ! Si en effet cette liste est stockée dans Species, la classe Species devra avoir quelque part un #include "individual.h". Mais si le constructeur d'Individual reçoit une reférence de type Species, il devra avoir #include "Species.h". Et ceci ne va pas tourner en rond ? C'est le pb de compilation dont je parlais quand j'ai voulu mettre un pointeur dans Individual vers Species. A moins que tu ne compte pas stocker la liste d'Individual dans Species. Or ceci doit absoluement être fait au vu de mon projet...

Enfin je sors à l'instant d'une entrevue avec ma supervisor pour ce projet. Et elle m'a conseillé l'héritage ! Or c'est apparement une sacré reférence dans le monde du code. Même si je comprends qu'il y a quelque chose qui cloche avec l'héritage ici, je n'ai pas su lui expliquer proprement (en Anglais qui plus est ) pourquoi je pensais que l'héritage ne collait pas ici. Il est vrai que d'un point de vue "de code", c'est quand même la solution qui regle tous mes problèmes !

Donc où est le souci finalement ?

Me voilà rendu au point de départ... J'ai l'impression de me prendre la tête pour pas grand chose ! (mais n'est-ce pas le but de l'informatique finalement )

[poukill]

Te prendre la tête pour pas grand chose??? Peut-être!!

Sans rire, l'héritage n'est pas une bonne solution...
Regarde attentivement ce que propose la STL : std::vector ou bien std::list.
Ne réinvente pas la ROUE !
Pourquoi une liste chaînée? Un individu est lié à un autre? Normalement non!

Quand aux "fichier.h", ils doivent normalement inclure un protection contre l'inclusion infinie, du genre:

Code :

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

1
2
3
4
5
6
7
8
#ifndef INDIVIDU_H
#define INDIVIDU_H
 
 
// ton code
 
 
#endif

Ensuite, il se peut qu'une simple déclaration du genre :

Code :

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

class Species;

suffise à la place de

Code :

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

#include "species.h"

Bonne continuation!

[loufoque]

Quoi qu'il en soit, je garde cette idée comme solution de secours uniquement. Je reste persuadé que ce n'est pas bien propre et qu'il y a mieux à faire.

Si, avec un design OO, il te faut downcaster, alors autant prendre la solution avec un entier.

[Maerlyn]

Quand aux "fichier.h", ils doivent normalement inclure un protection contre l'inclusion infinie, du genre:

En effet, et j'ai bien introduit ce type de protection (chui pas si un gros noob que ça ). Mais je ne parle pas d'inclusion à l'infini. Je vais essayer de t'expliquer mon problème.

Si dans mon species.h j'ai ceci :

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
 
#ifndef SPECIES_H 
#define SPECIES_H     
#include "individual.h"
 
class Species {
 
public :
...
 
private :
 
Individual* ptr; //pointeur vers le premier element de ma liste chainée
}
 
#endif

Et voici la tronche de l'"individual.h" :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
#ifndef INDIVIDUAL_H 
#define INDIVIDUAL_H     
#include "species.h"
 
class Individual {
 
public :
...
 
private :
Species* ptr; //pointeur vers l'espece de l'individu afin de savoir de quelle race il est
}
#endif

Ce qu'il se passe, c'est que lors de la compilation du species.h, il voit l'include "individual.h" donc il va le regarder. Et là, il tombe sur un pointeur de Species, et il ne sait pas ce que c'est vu qu'il n'a pas fini de créer la classe Species. Une erreur se produit donc en me disant que Species n'est pas un type !

Et j'ai bien peur que la même chose se produise, même si je n'utilise pas de pointeurs, mais des std::list, verctors, ou des références. Les types Individual et Species seront bien présent l'un dans l'autre et l'autre dans l'un (si cela veut dire quelque chose !)
Enfin, tu vois ce que je veux dire ?

Quoi qu'il en soit, je jete de suite un oeil à ces std::list et vector... Je sens que ça va m'etre utile.

[poukill]

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
#ifndef INDIVIDUAL_H 
#define INDIVIDUAL_H     

class Species;

class Individual {

public :
...

private :
Species* ptr; //pointeur vers l'espece de l'individu afin de savoir de quelle race il est
}
#endif

devrait suffire !!

[mchk0123]

Pour ce qui est ta prof et de sa volonté de te faire faire de l'héritage, je crois comprendre son point de vue.

En fait, manipuler des "Espece" et "Individu" est ambigu du point de vue de la modélisation. Ces 2 termes ont des sémantiques différente selon la définition qu'ont leur donne. On peut aussi dire les choses autrement : selon la nature du problème que ta modélisation doit résoudre, il est mieux de modéliser soit par une aggrégation, soit un héritage.

Donc premier point de vue (celui qui a été abordé jusqu'ici) : une "Espece" est un regroupement d'Individu. Autrement dit, une espèce EST DEFINIE par les réprésentants qui la compose. L'exemple typique étant "Humains" contient "John", "Steven", "Jorgen", "Larsen" (petit clin d'oeil à l'expatrié :lol).

L'autre point de vue étant de considérer une Espèce comme un modèle de certains types d'Individus. Autrement dit une espèce EST DEFINIE par l'ensemble des attributs communs à tous les représentants de cette espèce.
L'exemple typique étant : tout individu à un poids, donc pourquoi ne pas mettre l'attribut poids dans la classe Espèce (de même que la taille et une fonction de calcul de ratio poids / taille par exemple). Ainsi si on fait dériver Humain et Animal de Espèce, ont aura bénéficié de l'abstraction mise dans la classe mère.

En fait pour arriver à une modélisation correcte, si j'était toi j'introduirai la notion de "Groupe". Qui est nettement moins ambigu, car elle correspond uniquement à la définition 1 (car nottament un groupe peut être composé d'individus hétérogènes appartenant à plusieurs espèces différentes).

Autrement dit Animal, Humain, Chien, Homme, Femme héritent tous directement ou indirectement de Espece (sorte de méta-classe mère).
Alors que "John", "Mary", "Droopy" sont des instances des classes précédentes.
Enfin, Groupe aggrège via un attribut std::list<Espece*> un ensemble come "John", "Mary", ...

Les lecteurs assidus auront remarqué qu'au passage j'ai fait passer à la trappe la classe "Individu" qui n'existe plus. Pour la simple raison que pour moi un "Individu" est implicitement toute instance de l'une des espèces ci-dessus.

Aprés, sur ce problème, on peut vraiment en discutter jusqu'au bout de la nuit ...

Merci à ceux qui auront eu la volonté de me lire jusqu'au bout .

[poukill]

Mouais, je suis pas convaincu !!

espèce biologique : ensemble de populations interfécondes (interfertiles), isolées du point de vue reproductif d'autres ensembles équivalents

Je pense que je vais avoir du mal à faire passer mon opinion clairement. Mais ce qui est sûr, c'est qu'ici l'héritage me gêne énormément...
Espèce est très général, c'est un Abstract Data Type, et Individu est trop particulier.
Franchement à part le poids, je vois pas trop ce qu'on pourrait y mettre, il existe des espèces si différentes: les baleines, les moutons, les araignées etc... avec leur mode de reproduction différents... Certaines sont ovipares, d'autres vivipares...

De plus, l'individu n'est pas une spécialisation de l'espèce, mais un membre de l'espèce. Tu vas rajouter un tas d'arributs etc... pour chaque espèce différente. Y'a quelques chose de pas logique là dedans.

Enfin, de manière purement informatique, tu ne peux pas substituer uns instance d'individu à la place d'une instance d'espèce, ça n'a RIEN à VOIR!

Je sais que j'ai pas été clair, mais c'est pas évident de l'être là !

[mchk0123]

Ouais d'accord avec toi.

En fait j'aurais dut plutôt utiliser la notion de classe "EtreVivant" plutôt que "Espece" dans mon exemple précédent.

[Graffito]

Bonjour,

J'ai pas tout compris, mais je verrai le problème ainsi :
- définir une classe "Animal" générique avec ses propriétés comme Locomotion, couleur, régime alimentaire, dimension, ...
- définir différentes classes "Espèce" (ex: Mouton, Baleine) qui heritent de classe Animal,
- un individu est une instance de la classe (Mouton, Baleine, ...) à laquelle il appartient,
- définir une classe "Groupe_d'individus" qui est une collection d'Animaux.

Il est évidement possible d'intercaler une classe intermédiare "Embranchement" (Ex: "mamifère" ou "poisson") entre "Animal" et espéce.

Aussi, penser au double héritage, C++ est un des seuls langages qui l'accepte:
par exemple, un individu pourrait hériter de son "espéce", mais également de son "territoire".

[koala01]

Salut,

La question du "est un/a un" est tres subjective pour décider de se tourner vers l'héritage ou vers l'agrégation, et largement insuffisante.

N'oublions pas que le C++ permet, non seulement, l'héritage multiple, mais aussi l'héritage "non publique" (qu'il soit "protected" ou "private")

Or, il faut bien etre conscient que "jhon", est un humain parce qu'il est:

• un mamifere (par opposition à ovipare ou autre)
• un animal terrestre (par opposition à marin)
• omnivore (par opposition à herbivore, carnivore, charognard ou autre)
• bipede (par opposition à quadrumane, quadrupede, plantigrade ou autre)
• (intelligent)
• ...

Et que changer une (ou pire, plusieurs) de ces caractéristiques (propres à l'humain), revient à faire de jhon un tigre, un daufin, une girafe, un chimpanzée...Ou peut etre meme un vautour

Et, si la nature d'un objet dépend d'une classe moins spécialisée au point que le fait de changer un élément de cette classe moins spécialisée provoque le changement de la nature de l'objet concerné, l'héritage doit etre la seule solution retenue, quitte à ce que la visibilité de l'héritage ne soit pas publique...

Ainsi, il y a *peut etre* lieu d'arriver, par agrégation des termes utilisés dans la liste ci-dessus d'arriver aux classes chat, chien, mouton, tigre, daufin, girafe etc, qui pourraient toutes hériter d'une classe "espece"(species) et de considérer la classe "individu" comme une interface, car tous les individus auront des comportement similaires: manger, dormir, se reproduire, se déplacer...

A partir de là, il est bon de prévoir des classes "individuchat", "individuhumain", "individuchien" etc qui héritent en public (et en redéfinissant les comportements si besoin) d'individu, et en privé des classes chat, humain, chien, tigre ou daufin...

De cette manière, tu pourras définir john comme étant un individuhumain, droopy comme étant un individuchien et flipper comme étant un individudaufin, tout en les placant tous les trois dans un conteneur utilisant le type indiviu

[mchk0123]

Bien vu koala, tu vas plus loin que ce que je proposais : un double héritage.

Je rajouterais simplement une classe "GroupeDIndividus" qui n'aurait uniquement comme sens de modéliser une aggrégation d'"Individus" (regroupement possible d'Individus hétérogènes).