Polymorphisme et méthode

Bonjour.

Pas moyen de trouver une solution simple à cette considération théorique. Vu qu'elle a quelques application pratiques ; j'espère que vous pourrez m'aider :)

Je me trouve dans un cas où j'ai un objet Parent qui a plusieurs types d'enfants : Enfant1, Enfant2, etc... (le nombre d'objets héritant de Parent n'étant pas parfaitement défini ; celui ci pouvant être amené à évoluer)

J'ai maintenant un objet Maternité qui a une méthode "accouchement()" qui doit générer un "ensemble" d'Enfants (ceux ci pouvant être des Enfant1, Enfant2, etc...)

Question : quelle "tête" peut avoir cet ensemble de manière à faire quelque chose de "simple" ?

Mon problème vient du fait que -sauf erreur de ma part- si je me contente de vouloir caser tous ces Enfants dans un vecteur je vais devoir considérer un vecteur de pointeurs sur Parent. Or ces pointeurs vont pointer sur des Enfants qui ont été créés par la méthode "accouchement()" et qui vont donc avoir une portée locale. Il seront donc détruits à la fin de cette l'exécution de cette méthode et on retournerait un vecteur de pointeurs pointant sur rien...

Bref, me trompe-je avec cette histoire de vecteur ?
Si non, quelle alternative simple peux-t-on utiliser ?

Merci d'avance pour vos réponses

Pour moi, avoit un Objet Maternité est une erreur de conception.

Maternité est plutot un etat que peut prendre l'objet Parent (le parent féminin, évidemment - quoi qu'avec la science aujourdhui, faut se méfier), et le parent pouvant accoucher, c'est à lui que revient la méthode accoucher()...

de plus, pour gérer l'héritage, il serait logique que ce soit le parent qui ait une liste (vector why not) de ses enfants, ou si tu veux gérer la biparentalité, que chaque enfant ait 2 pointeurs, un vers le père, un vers la mère...



D'ailleurs, en toute rigueur, tu ne devrais avoir qu'une seul classe "Personne", qui a certains attributs comme "homme/femme", "enceinte", et des methodes en conséquence, telles que "accoucher" ou "prendre un congé de paternité"...

du coup, dans ton arbre généalogique, tu n'as que des "Personnes", dont les enfants sont aussi des "Personnes"... la différence entre les parents et les enfants est logiquement un attribut "age".

Ici, l'héritage de classe n'a pas vraiment de sens si tu veux faire hériter les enfants des parents.
le sens que ca pourrait prendre est de faire hériter des classes "Homme" et "Femme" d'une classe "Personne" (ou "Humain")

boost::ptr_vector<Parent>
std::vector< std::unique_ptr<Parent> > (C++0x only)
std::vector< clone_ptr<Parent> > (ou équivalent, peu performant si pas en C++0x ou pas de COW)
std::vector< boost::shared_ptr<Parent> > (ou équivalent, c'est moche parce que y'a pas vraiment de partage de propriété)

Citation:

---

Envoyé par loufoque

boost::ptr_vector<Parent>
std::vector< std::unique_ptr<Parent> > (C++0x only)
std::vector< clone_ptr<Parent> > (ou équivalent, peu performant si pas en C++0x ou pas de COW)
std::vector< boost::shared_ptr<Parent> > (ou équivalent, c'est moche parce que y'a pas vraiment de partage de propriété)

---

Loufoque, c'est sympa de pondre des solutions techniques, mais a quoi cela sert de poser des rustines à coup de code sur un design bancal ?

L'exemple est en effet peut-être mal choisi ; en fait il s'agissait plus d'illustrer d'une manière simple ce point théorique auquel je suis confronté : comment générer un ensemble d'Enfants.

Je conçois que "si tu te retrouves face à un tel cas c'est que t'as mal architecturé ton programme" puisse être ma réponse ; mais en admettant que je me retrouve face à ce cas malgré une bonne conception, comment serait-il possible de s'en sortir ?

Tu ne peux pas te passer de pointeurs ici :

Code:

---

std::vector<Parent* > vp;

---

Si tu n'utilises pas de pointeurs, ton vector n'enregistrera que des parents, même si tu lui donnes un Enfant, il enregistrera un parent à partir de la partie Parent de l'Enfant.

Pour que ça dépasse le cadre d'une fonction, il te faut faire de l'instanciencion dynamique :

Code:

---

vp.pushback(new Enfant);

---

La question que tu dois te poser maintenant, c'est qui gère la durée de vie de ces objets, car à tout new doit correspondre un delete (appel au destructeur et libération de la mémoire). Si c'est la maternité qui gère leur existence, le plus simple sera de le faire dans le destructeur :

Code:

---

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

// Constructeur Maternite::Materinte(int nb) { for(int i = 0; i < nb; ++i) vp.push_back(new Enfant); }   // Ajout void Maternite::accouchement() { vp.push_back(new Enfant); }   // Destructeur Maternite::~Maternite() { for(vector<Parent*>::iterator it = vp.begin(); it != vp.end(); ++it) delete (*it); }

---

Mon code devrait être juste, mais je ne l'ai pas vérifié, c'est seulement pour te donner une idée. Attention, parce-que ça ajoute des pointeurs à la liste de pointeurs, ne les crée qu'avec un objet Enfant associé, et si tu détruits un objet Enfant du vector autre-part que dans le destructeur de Maternite, il faudra aussi que tu enlèves le pointeur.

Enfin, tu veux utiliser le polymorphisme, alors n'oublie pas de mettre le destructeur et les méthodes à redéfinir en virtual.

Honnêtement, tu devrais t'assurer de bien connaître les pointeurs et les vector avec ses itérateurs avant de te lancer là-dedans, parce-que sinon ce sera un nid à erreurs :(

Effectivement vu comme ça je comprend qu'il soit plus pertinent de se poser davantage de questions au niveau de la conception...

Je vous remercie de m'avoir fourni autant de réponses si rapidement. Ces informations répondent parfaitement à mes questions. :)

Citation:

---

Envoyé par _ash_

mais en admettant que je me retrouve face à ce cas malgré une bonne conception, comment serait-il possible de s'en sortir ?

---

alors c'est que l'exemple est mal choisi ^^

et sans exemple correct, concretement, je ne peux pas t'aider plus, car ton besoin n'est pas purement générique, et que en fonction des cas, on va plutot choisir un design plutot qu'un autre.

donc on recommence du debut. tu as un exemple mieux expliqué ? :aie:

Citation:

---

tu as un exemple mieux expliqué ?

---

En fait non : vos réponses me permettent de voir qu'il n'y a pas que mon exemple qui est mal fichu : mon cas pratique aussi ! :aie:

Bref, encore merci : ces réponses m'ont vraiment aidé ! :)

Citation:

---

Envoyé par _ash_

En fait non : vos réponses me permettent de voir qu'il n'y a pas que mon exemple qui est mal fichu : mon cas pratique aussi ! :aie:

Bref, encore merci : ces réponses m'ont vraiment aidé ! :)

---

de rien, et n'hésite pas si tu as d'autres doutes de cet ordre la, c'est toujours mieux de se rendre compte de ce genre d'erreur avant de commencer à coder...
un bon design, c'est du temps gagné à coder !!!

Citation:

---

Envoyé par toxcct

un bon design, c'est du temps gagné à coder !!!

---

Je plussoie avec véhémence. Même chez les scientifiques de haut niveau, tout le monde s'accorde à dire que bien souvent, exposer un problème de façon claire permet de le résoudre.

Citation:

---

Envoyé par Obsidian

Je plussoie avec véhémence. Même chez les scientifiques de haut niveau, tout le monde s'accorde à dire que bien souvent, exposer un problème de façon claire permet de le résoudre.

---

meme à l'époque ils disaient deja :

Citation:

---

"Qui se comprend bien s'ennonce clairement, et les mots pour le dire viennent aisément"

---

Un vecteur de pointeurs c'est quasiment toujours une mauvaise solution (de manière générale, je généraliserais même ça à tout pointeur)
Ce n'est pas conforme au RAII, et donc pas exception-safe.

Tu remplacerais par boost::ptr_vector ?

Citation:

---

Envoyé par toxcct

Pour moi, avoit un Objet Maternité est une erreur de conception.

---

Je suis globalement en accord avec tes commentaires, sauf sur ce point.

Ca ne me choque pas de dire que la maternité (pas le fait d'enfanter, mais l'établissement qui au sein de l'hôpital s'occupe de cette action) soit une factory d'enfants. Ca ne reproduit pas la réalité de notre monde, certes (encore qu'avec certaines expériences eugénistes...), mais là n'est pas le but d'un programme. Et je peux voir plein de cas où avoir une factory d'enfants, à laquelle d'adresse éventuellement une mère voulant avoir un enfant, aurait un avantage par rapport à un design où le seul moyen de créer une personne passerait par ses parents (générer une population initiale, gérer des parents inconnus, étendre le système à un environnement où la génération spontanée existe,...).

Comme souvent en matière de conception, il est difficile de donner des réponses définitives sans savoir vraiment à quoi va servir un logiciel, et avec bien plus de détails que ce que l'on peut supposer en voyant juste le nom de quelques classes.

Tout à fait d'accord avec l'argumentation de Loïc. Une factory d'enfants peut s'avérer très pratique !

Ca déprend après du contexte global et des classes qui vont intéragir avec, etc...

Citation:

---

Envoyé par JolyLoic

Je suis globalement en accord avec tes commentaires, sauf sur ce point.

Ca ne me choque pas de dire que la maternité (pas le fait d'enfanter, mais l'établissement qui au sein de l'hôpital s'occupe de cette action) soit une factory d'enfants.

---

Bien vu. En fait, là où j'ai divergé, c'est que j'ai pris l'autre sens du mot Maternité (celui qui traduit plutot le fait "d'etre mère").
Donc comme je le disais, et tu l'as reprécisé, il faut des "specs" plus claires :)