[Conception] Problème de visite typée

Salut,

J'ai une famille de classes pour lequelles j'ai défini une interface commune pour recevoir un visiteur :

La classe mère a la méthode suivante:

Code:

---

virtual void accept(Visitor* visitor);

---

qui fait tout simplement :

Code:

---

visitor->visit(this);

---

La méthode visit du visiteur peut recevoir plusieurs types dans la chaine d'héritage de la classe mère c'est à dire qu'il y a :

Code:

---

1 2 3 4 5 6 7

class Visitor { public: void visit(ClasseMere* instance); void visit(ClasseFille1* instance); void visit(ClasseFille2* instance); }

---

Mon problème est le suivant :

Si je créé un visiteur et que je le donne à la méthode accept() une instance de ClasseFille1 alors le code

Code:

---

visitor->visit(this)

---

me branche sur la méthode

Code:

---

void visit(ClasseMere* instance);

---

au lieu de

Code:

---

void visit(ClasseFille1* instance);

---

Je m'attendrais en effet à ce que visit() s'adapte au type concret ClasseFille1 de mon instance.

Par contre j'ai remarqué que si je redéfini accept() dans ClasseFille1 :

Code:

---

virtual void accept(Visitor* visitor);

---

avec un code identique :

Code:

---

visitor->visit(this);

---

Alors c'est bien la méthode :

Code:

---

void visit(ClasseFille1* instance);

---

qui est appelée

Qui aurait une explication ? Quelle est la bonne façon de faire ?

Merci

La description du pattern Visitor sur Wikipédia indique qu'il faut bel et bien redéfinir la méthode accept()...

Citation:

---

Envoyé par Médinoc

La description du pattern Visitor sur Wikipédia indique qu'il faut bel et bien redéfinir la méthode accept()...

---

L'exemple de wikipedia ne correspond pas tout à fait à mon cas car "Engine", "Body", "Wheel" n'héritent pas d'une classe "Parts" par exemple.

L'équivalent de mon problème serait qu'il y ait une classe "Parts" mère de "Engine", "Body", "Wheel" et qui définirait accept() comme faisant :

Code:

---

visitor.visit(this);

---

Je ne vois pas alors pourquoi ce code hérité de "Parts" ne marcherait pas en adaptant l'appel de "visit()" au type concret de "this" lorsqu'il est appelé depuis les classes filles "Engine", "Body", "Wheel".

Parce que le choix de l'une ou l'autre méthode visit() dépend du type statique de l'argument qu'on lui passe.

C'est le principe même du pattern Visitor.

Citation:

---

Envoyé par Médinoc

Parce que le choix de l'une ou l'autre méthode visit() dépend du type statique de l'argument qu'on lui passe.

C'est le principe même du pattern Visitor.

---

Ah d'accord, je n'avais pas compris cette subtilité... celà explique en effet le comportement observé.

Dois-je en conclure que je n'ai pas d'autre alternative que de définir un accept spécifique pour chacune de mes classes ?

N'y aurait-il pas un moyen de s'en sortir avec une utilisation des templates par exemple ?

Avec les templates, peut-être en CRTP (curiously recurring template pattern) avec une classe intermédiaire TParts qui serait le template.

Code:

---

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

class Parts { virtual void accept(Visitor * pVisitor) = 0; }   template< class T > class TParts : public Parts { virtual void accept(Visitor * pVisitor) { pVisitor->visit(static_cast< T* >(this); } };   class Engine : public TParts< Engine > { };   //etc.

---

Note que la classe TParts réimplémente quand même la méthode accept(). Par contre, les classes qui en dérivent n'en ont pas besoin, puisque le type statique est le bon.

Citation:

---

Envoyé par Médinoc

Avec les templates, peut-être en CRTP (curiously recurring template pattern) avec une classe intermédiaire TParts qui serait le template.

---

Merci beaucoup...je sentais qu'il y avait une possibilité mais je ne ne la voyais pas concrètement.

Sinon pour cette histoire de type statique sur lequel le compilateur se base pour choisir la bonne version d'une fonction... Je trouve que c'est un peu surprenant que ce soit *LA* seule règle qui puisse s'appliquer en C++ quand on sait ce qui est fait par ailleurs comme contorsions dans le langage pour obtenir des évaluations dépendantes du type dans une chaine d'héritage. Ca ne choque personne d'autre ?

Première note, on n'a pas ici un pattern visiteur -- à moins que l'exemple ait été simplifié au point de l'enlever -- mais simplement l'idiome C++ permettant d'implémenter le dispatch multiple. Comme il est nécessaire pour implémenter le pattern visiteur en C++, l'idiome est trop souvent présenté en même temps, ce qui crée de la confusion au point que certains oublient ce qu'il y a derrière le visiteur: une structure de donnée complexe à visiter.

La surchage permet d'avoir plusieurs fonctions ayant le même nom, le choix de la fonction s'effectuant d'après le type des paramètres. Ce choix peut s'effectuer avec le type statique ou avec le type dynamique des paramètres. Dans les langages statiquement typés, on a tendance à réserver le mot surcharge au cas où la résolution est faite avec le type statique et de parler de dispatch dynamique dans le cas où le type dynamique est utilisé.

Le C++ fournit de la surcharge et du dispatch dynamique sur un paramètre (this, via le mécanisme des fonctions virtuelles). Si on veut implémenter du dispatch dynamique sur plusieurs paramètres, il faut le faire à la main et chainer deux appels faisant un dispatch chacun sur un paramètre. C'est ce qui est fait ici: accept effectue un dispatch sur le paramètre de la hiérarchie de ClasseMere, visit effectue un dispatch sur le paramètre de la hiérarchie de Visiteur en utilisant la surcharge (statique) pour déterminer statiquement la fonction à utiliser dans la hiérarchie de ClasseMere. Les choses seraient peut-etre plus claire si la surcharge n'était pas employée, ce qui est possible (plus ajout de virtual nécessaires):

Code:

---

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

class classeMere; class classeFille1; class classeFille2; struct Visitor { virtual void visitMere(ClasseMere* instance); virtual void visitFille1(ClasseFille1* instance); virtual void visitFille2(ClasseFille2* instance); }; struct classeMere { virtual void accept(Visitor& v) {v.visitMere(this); } }; struct classeFille1: classeMere { virtual void accept(Visitor& v) {v.visitFille1(this); } }; struct classeFille2: classeMere { virtual void accept(Visitor& v) {v.visitFille2(this); } };

---

Citation:

---

L'exemple de wikipedia ne correspond pas tout à fait à mon cas car "Engine", "Body", "Wheel" n'héritent pas d'une classe "Parts" par exemple.

---

Ils héritent de Visitable (les interfaces de Java ne sont rien d'autres qu'une forme réduite d'héritage virtuel).

La virtualité n'est disponible que pour l'objet auquel s'applique la fonction virtuelle.
On n'a donc en C++ que du "simple dispatch". Si tu veux simuler du "double dispatch", tu dois passer par le pattern Visitor, ou par des trucs moins "C++" (genre, un tableau à deux dimensions de pointeurs de fonction).

Edit: Grillé par Jean-Marc.

Par contre, sans surcharge, l'on doit forcément définir à la main dans chaque classe fille : On ne peut plus jouer avec le CRTP pour compenser sa paresse...