Conception d'un éditeur de propriétés

Bonjour !

Je me retrouve avec un petit problème dans mon éditeur de propriétés, je ne parviens pas à déterminer comment le résoudre. Pire, je ne sais pas s'il s'agit au final d'un problème de conception, ou d'un problème de compréhension du C++ ! (et dans ce dernier cas, ça me ferait bien ****)

Cet éditeur est censé permettre d'éditer les propriétés de disons, tous les objets dérivés d'une classe Geometry (non héritée de QObject).

Ma classe, appelons-la PropertyEditor, contient un slot "setCurrentEditable(Geometry *)". Cette fonction affiche dans les propriétés de l'instance de Geometry dans des widgets et permet de les éditer.

A ce slot est connecté le signal "objectSelected(Geometry *)", émis par une autre classe.

Le problème est le suivant :

lorsqu'un objet de type Cube, dérivé de Geometry, est sélectionné, la modification des propriétés n'est pas répercutée...car j'opère à coups de dynamic_cast...qui me retourne un nouveau pointeur et pas le pointeur vers l'instance de l'objet sélectionné.

Je sèche vraiment, et c'est la première fois.

Merci à tous.

Salut,

Citation:

Envoyé par GilbertLatranche

lorsqu'un objet de type Cube, dérivé de Geometry, est sélectionné, la modification des propriétés n'est pas répercutée...car j'opère à coups de dynamic_cast...qui me retourne un nouveau pointeur et pas le pointeur vers l'instance de l'objet sélectionné.

Je sèche vraiment, et c'est la première fois.

Merci à tous.

Rien qu'à lire ces dernières lignes, j'ai presque envie de dire que c'est un problème de conception :aie:

De manière générale, l'utilisation d'un dynamic_cast est souvent le symptome d'un problème de conception, surtout si elle prend une forme proche de
Code:

1 2 3 4 5 6 if (un test quelconque) dynamic_cast<UnTypeDerive *>(ptr)->uneFonction(); else if (un autre test) dynamic_cast<UnAutreTypeDerve *>(ptr)->uneAutreFonction(); else if(...) /* bon ben, tu as compris hein :-D */
Typiquement, la solution à ce genre de problème tient en deux mots : double dispatch.

L'idée générale est de se dire que tout objet qui est connu "comme étant de type Geometry" car connu grâce à un pointeur de ce type sait parfaitement de quel type réel il est : un cube sait qu'il est un cube et non une sphere ou un triangle, et il en va de même pour chaque type dérivé de Geometry.

On peut donc s'organiser pour demander à l'objet lui-même d'invoquer un comportement spécifique. La manière dont on s'y prend n'a finalement que peu d'importance, tout ce qui importe, c'est que la classe Geometry expose un comportement qui pourra être redéfini dans les classes dérivées.

Une solution "classique" (mais qui n'est pas forcément la meilleure ;)) est d'utiliser le patron de conception connu sous le nom de visiteur (Visitor en anglais).

Le principe en est relativement simple et se base sur deux hiérarchies de classes distinctes :

les objets visités d'une part, qui correspond à tous les types qui dérivent de Geometry et
les visiteurs d'une autre, qui correspond à "tout ce qui doit être en mesure de faire la différence entre les différents types d'objets dérivés de Geometry".
Pour savoir de quoi on parle, je vais nommer la classe de base de la deuxième hiérarchie "Visitor". Ce sera plus simple pour la compréhension ;).

On rajoute à la classe Geometry une fonction virtuelle (éventuellement pure) qui prend en argument un pointeur (ou mieux une référence, constante si possible :P) vers un objet de type Visitor. Pour savoir de quoi on parle, nommons cette fonction accept ;).Cela pourrait donc prendre la forme de
Code:

1 2 3 4 5 class Geometry{ public: virtual void accept(Visitor &) const = 0 ; /* tout le reste de ta classe Geometry qui ne change absolument pas */ };
Cette fonction sera redéfinie de manière très simple, identique dans tous les types dérivés de Geometry sous une forme qui ressemblerait à
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 class Cube : public Geometry{ public: void accept(Visitor & v) const{ v.visit(*this); } }; class Sphere : public Geometry{ public: void accept(Visitor & v) const{ v.visit(*this); } }; class Paralelogram : public Geometry{ public: void accept(Visitor & v) const{ v.visit(*this); } };
Comme tu peux le remarquer, cette fonction invoque systématiquement une fonction visit en lui transmettant ce qui est pointé par le pointeur this, qui correspond à l'objet (réel) au départ duquel la fonction accept a été invoquée.

Notes que le nom de la fonction visit est choisi tout à fait arbitrairement et que chaque classe dérivée de Geometry pourrait sans aucun problème décider d'appeler une fonction portant un nom différent. L'implémentation de la fonction accepte pourrait d'ailleurs décider d'appeler une fonction libre quelconque ;)

Il ne reste plus qu'à nous intéresser au visiteur. L'idée est que le visiteur "de base" devra être en mesure de faire la distinction entre la classe Sphere et la classe Cube. La classe Visitor qui servira, comme je te l'ai dit de classe de base à "tout ce qui doit être en mesure de faire la différence entre les différents types d'objets dérivés de Geometry" devra donc exposer une fonction "visit" prenant comme paramètre une référence (éventuellement constante) vers chacune des classes dérivées de Geometry.

Elle ressemblera donc à quelque chose comme
Code:

1 2 3 4 5 6 7 class Visitor{ public: virtual void visit(Cube const &) = 0; virtual void visit(Sphere const &) = 0; virtual void visit(Paralelogram const &) = 0; /* et tous les autres types dérivés de Geometry */ };
Une fois que tu es rendu à ce point, il ne te reste plus qu'à définir les comportements spécifiques aux différents visiteurs dont tu as besoin.

Ainsi, ta classe PropertyEditor pourrait ressembler à quelque chose comme
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 class PropertyEditor : public QWidget, // tu as peut etre choisi une classe de base moins générique ;) public Visitor{ public: virtual void visit(Cube const & c){ /* ce qui doit etre fait, spécifique à un cube */ } virtual void visit(Sphere const & s){ /* ce qui doit etre fait, spécifique à une sphère */ } virtual void visit(Paralelogram const & p){ /* ce qui doit etre fait, spécifique à un parallélogramme */ } /* et tous les autres types dérivés de Geometry */ public slots : /* n'oublions pas le slot auquel tu connecte le signal */ setCurrentEditable(Geometry * g){ /* c'est simple : on appelle la fonction accept de geometry */ g->accept(*this); } };
Et voilà, le tour est joué! Tu obtiens quelque chose qui ne pourra pas se tromper de type et qui pourra évoluer très facilement.

Il y a cependant une chose un peu contraignante à prendre en compte : Si tu décides de rajouter un nouveau type dérivé de Geometry, tu devras, forcément, déclarer une nouvelle fonction "visit" prenant le type correspondant en argument dans la classe de base Visitor, mais tu devras aussi rajouter une définition de cette fonction dans tous les visiteurs existants :aie:

D'un autre coté, comme il y a de fortes chances pour que tous les visiteurs doivent effectivement adapter leur comportement pour le nouveau type dérivé de Geometry, cela t'obligera surtout à t'assurer que ce soit bel et bien le cas, car le compilateur sera plus têtu que toi si ce n'est pas le cas ;)

Tout d'abord, je voudrais te remercier vraiment pour la longue réponse que tu m'apportes, j'ai aperçu que tu me proposais d'utiliser le pattern Visiteur (que je pensais utiliser hier).

Avant de m'attaquer à cette lecture, mon "problème" de dynamic_cast est résolu. En utilisant QtPropertyBrowser et les cast, c'est fonctionnel. Les adresses différentes obtenues venaient du fait que la mémoire n'était pas correctement désalouée lorsqu'on changeait de scène 3D...

(c'est quand même dingue, 3 sujets d'affilée que je ponds, et 3 bugs dus à la patate qui se trouve sur la chaise...)

Merci encore ;)