Design d'une classe collection

Design d'une classe collection - C++ - Programmation

Marsh Posté le 15-06-2005 à 01:26:55    

Hello
 
Ma question porte sur le design de deux classes que nous appellerons Truc et TrucCollection.
 
Ce que je voudrais faire : TrucCollection conserve toujours la liste de toutes les instances des "Truc", sans que "l'utilisateur" n'est de méthode spécifique à appeller.
 
classe TrucCollection :
 

Code :
  1. class TrucCollection
  2. {
  3. public:
  4.     static void addInstance(Truc *); // ajoute cette instance
  5.     static void removeInstance(Truc *); // supprime cette instance
  6. private:
  7.     static un_conteneur_STL<Truc *> liste;
  8. }


 
classe Truc :

Code :
  1. class Truc
  2. {
  3. public:
  4.     Truc() { TrucCollection::addInstance(this); }
  5.     ~Truc() { TrucCollection::removeInstance(this); }
  6. }


 
Jusque là, ça fonctionne. Maintenant je veux ajouter une méthode "mrproper()" à la classe TrucCollection qui supprime toutes les instances (en fin de programme par exemple). Le problème est le suivant :

Code :
  1. void mrproper()
  2. {
  3.     for (...) // parcours de la liste
  4.         delete element; // appel le destructeur, qui va le retirer de la liste qu'on est en train de parcourir !
  5. }


 
Retirer l'element d'une liste alors qu'on est en train de la parcourir, est-ce bien moral ? Est-ce mon design qui n'est pas correct ? Y a-t-il d'autres solutions ?
 
Merci d'avance pour vos conseils !

Reply

Marsh Posté le 15-06-2005 à 01:26:55   

Reply

Marsh Posté le 15-06-2005 à 02:00:43    

Je ne suis pas un pro mais je penses pas que ca soit moche ce que tu fais.
 
Tu ne "retire" pas d'éléments dans ta liste ! Elle conserve ses éléments qui sont des pointeurs. Tu vide juste les objets Trucs qui sont à leurs addresses. A la limite tu peux mettre les pointeurs à NULL apres le delete pour plus de cohérence mais si tu fais ca en fin de programme, alors cela n'a pas d'importance.

Reply

Marsh Posté le 15-06-2005 à 02:34:37    

J'ai peur de me tromper, mais est-ce que le pattern Factory ne sert pas à ça justement?

Reply

Marsh Posté le 15-06-2005 à 10:02:48    

Ce qui me gène aussi c'est au niveau de la logique du truc :
- dans mrproper() je suis dans une boucle, j'ai l'itérateur sur l'objet à supprimer
- j'appelle le destructeur de l'objet
- le destructeur appelle removeInstance() qui _reparcours_ la liste pour retrouver l'objet à supprimer !
 

haazheel a écrit :

J'ai peur de me tromper, mais est-ce que le pattern Factory ne sert pas à ça justement?


Tu veux dire par exemple des fonctions Truc::create() et Truc::destroy() pour l'utilisateur (et ducoup mettre les constructeurs/destructeurs normaux en protected/private) ?

Reply

Marsh Posté le 15-06-2005 à 10:14:20    

tu connais les opérateurs new / delete

Reply

Marsh Posté le 15-06-2005 à 13:37:51    

Taz a écrit :

tu connais les opérateurs new / delete


bah oui, mais je ne comprends pas le rapport avec ma question :heink:

Reply

Marsh Posté le 15-06-2005 à 13:48:36    

moi je comprends pas a quoi ca peu servir ?

Reply

Marsh Posté le 15-06-2005 à 19:45:36    

skelter a écrit :

moi je comprends pas a quoi ca peu servir ?


De quoi tu parles ?

Reply

Marsh Posté le 15-06-2005 à 19:48:38    

de TrucCollection

Reply

Marsh Posté le 15-06-2005 à 19:57:38    

Ah ok, ben en fait je voudrais conserver un pointeur vers toutes les instances de ma classe Truc, d'où qu'elles soient créées dans le programme, et sans que "l'utilisateur" ai besoin de les "enregistrer" manuellement. Par exemple il fait un Truc * toto = new Truc() et hop cette instance est automatiquement enregistrée dans TrucCollection.

Reply

Marsh Posté le 15-06-2005 à 19:57:38   

Reply

Marsh Posté le 15-06-2005 à 20:01:12    

et tu vois toujours pas le rapport là ?
 
 
cela dit, pourquoi tu ne fous pas un std:queue<> en static dans ta classe ?

Reply

Marsh Posté le 15-06-2005 à 20:07:47    

Taz a écrit :

et tu vois toujours pas le rapport là ?


euh non désolé.... mais ma question ne porte pas sur l'utilisation de new/delete (ça, ça fonctionne, regarde mon tout premier post), alors je ne vois pas trop où tu veux en venir...
 

Taz a écrit :

cela dit, pourquoi tu ne fous pas un std:queue<> en static dans ta classe ?


Hum ça apporterait quoi par rapport à ce que j'ai déjà mis dans la classe TrucCollection ?  :heink:

Reply

Marsh Posté le 15-06-2005 à 20:18:11    

cgo2 a écrit :

euh non désolé.... mais ma question ne porte pas sur l'utilisation de new/delete (ça, ça fonctionne, regarde mon tout premier post), alors je ne vois pas trop où tu veux en venir...


que t'as le droit de surcharger ces opérateurs.

Reply

Marsh Posté le 15-06-2005 à 20:36:56    

/me pas comprendre pourquoi toi pas faire une factory (et singleton la factory si tu y tiens)

Reply

Marsh Posté le 15-06-2005 à 20:54:39    

ben parcequ'au départ j'étais parti sur l'idée de pouvoir écrire "new Truc" et pas TrucFactory::create()...
 
je suis en train de regarder si la surchage de l'opérateur delete peut m'aider.

Reply

Marsh Posté le 15-06-2005 à 21:06:22    

ce que suggere taz c'est que au lieu d'avoir une classe TrucCollection tu met dans Truc la collection de pointeurs en static et tu surcharge new et delete de Truc pour qu'ils fassent eux meme   l'ajout et la suppression de this dans la collection, c'est nettement mieux

Reply

Marsh Posté le 15-06-2005 à 21:54:08    

oui c'est ce que j'avais enfin fini par comprendre (expliqué comme ça dès le départ ça aurait été beaucoup plus rapide ;) ducoup je peux résoudre mon problème initial en utilisant ::operator delete qui supprimera l'objet sans s'occuper de le retirer de la liste. merci beaucoup pour cette idée !
 
mais je me demande quel est l'avantage de mettre la liste en static dans la classe Truc ? par exemple si je décide d'implémenter des fonctions de traitements (afficher l'état de toutes les classes Trucs, faire une action, etc.) n'est-ce pas mieux de séparer :
- d'un côté les méthodes qui traitent une seule classe (dans Truc)
- et les méthodes qui traitent toutes les classes (dans TrucCollection) ?


Message édité par cgo2 le 15-06-2005 à 21:54:27
Reply

Marsh Posté le 16-06-2005 à 06:00:08    

Je crois bien que si, et c'est là justement qu'une factory entre en jeu il me semble...
 
http://www.dofactory.com/Patterns/ [...] spx#_self2

Reply

Marsh Posté le 16-06-2005 à 09:59:55    

Ok ok, merci pour ces conseils, j'ai maintenant deux pistes pour résoudre mon problème :
- soit surcharger new et delete au lieu de mettre le code dans les constructeurs/destructeur
- soit faire une factory, à priori plus adaptée, mais qui empecherait après d'utiliser la syntaxe new/delete
 :jap:

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed