Design pattern Visitor & double dispatching

Bonjour,

J'ai besoin de mettre en place une architecture qui m'oriente vers le design pattern Visitor (ie : ensemble de classes "noyau" et de nouvelles opérations à réaliser sur ces classes sans les polluer).

La question que je me pose est l'utilité de la méthode "Accept()" et du double dispatching dans ce cas?

Par exemple j'ai un ensemble de classes classe1, classe2, etc. sur lesquelles viendront agir les visiteurs Visitor1, Visitor2, etc.
Le livre du GOF propose une implémentation permettant d'utiliser le pattern ainsi :

Code:

---

1 2 3

classe1* maclasse; visitor1 visitor; maclasse->accept(visitor);

---

Cette dernière ligne conduira à appeler une fonction "visit()" du visiteur qui fera le job.

Je me demande pourquoi ne procède t'on pas directement ainsi comme suit?

Code:

---

visitor.visit(maclasse);

---

D'avance merci de m'éclairer. J'ai sans doute loupé quelque chose dans la logique du pattern et dans ses cas d'application.

Citation:

---

Envoyé par f56bre

Je me demande pourquoi ne procède t'on pas directement ainsi comme suit?

Code:

---

visitor.visit(maclasse);

---

---

Cela impliquerait de surchargé Visitor::visit pour toutes nouvelles classes pouvant acceptés un Visitor.

Salut,
Le principe du double dispatch et du visiteur doit se comprendre lorsqu'on désire 'descendre' simultanément 2 hiérarchies. accept permet d'atteindre l'élément concret idoine et visit sur celui du visiteur concret.
En fait, l'idée est que le conteneur ne connait pas le visiteur concret ni l'élément concret, mais n'est lié qu'avec leur classe de base (avec l'héritage ou une classe template supposée avoir la bonne fonction). Le double dispatch permet ainsi de descendre dans les 2 hiérarchies, ce que ne permettrait pas ta solution.
@Joel : c'est déjà le cas du pattern tel que présenté par le GoF et c'est un gros inconvénient de ce pattern. Cet inconvénient (et repris dans l'article cité plus bas) est précisé dans le GoF qui dit bien que la structure des types à visiter doit être stable sinon ça implique beaucoup de changement de code côté visiteur.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78

#include <iostream> struct visitor; struct element { virtual void accept(visitor const&)=0; virtual ~element(){} };   struct element_1; struct element_2;   struct visitor { virtual void visit_element_1(element_1 const&)const=0; virtual void visit_element_2(element_2 const&)const=0; virtual ~visitor(){} };   struct element_1 : public element { virtual void accept(visitor const&v_) { v_.visit_element_1(*this); } };   struct element_2 : public element { virtual void accept(visitor const&v_) { v_.visit_element_2(*this); } };   struct visitor_concret : public visitor { virtual void visit_element_1(element_1 const&)const { std::cout<<"visit d'un element 1\n"; } virtual void visit_element_2(element_2 const&)const { std::cout<<"visit d'un element 2\n"; } };   #include <vector> #include <boost/shared_ptr.hpp> struct conteneur { conteneur() { mes_elements.push_back(boost::shared_ptr<element>(new element_1)); mes_elements.push_back(boost::shared_ptr<element>(new element_2)); }   void visit(visitor const &v_) const { typedef std::vector<boost::shared_ptr<element> >::const_iterator iterator; for(iterator it=mes_elements.begin();it!=mes_elements.end();++it) { (*it)->accept(v_); } }   private: conteneur(conteneur const&); conteneur&operator=(conteneur); private: std::vector<boost::shared_ptr<element> > mes_elements; };   int main() { conteneur c; c.visit(visitor_concret()); return 0; }

---

Une lecture intéressante : V comme visiteur, de Deloget.

Citation:

---

Envoyé par 3DArchi

Une lecture intéressante : V comme visiteur, de Deloget.

---

Ah, et moi qui allais intervenir dans la discussion... :)

Salut Emmanuel,

Citation:

---

Envoyé par Emmanuel Deloget

Ah, et moi qui allais intervenir dans la discussion... :)

---

C'est clairement un article intéressant dès que l'on parle de visiteur.
Ceci dit, j'ai récemment relu la partie consacrée aux visiteurs du DP des GoF. Et quelque part, il me semble qu'ils étaient conscients du problème. Ils disent bien que le DP visiteur, du fait de l'absence de double dispatch, n'est à mettre en œuvre que lorsque la structure des objets à visiter sont stables. Donc, à priori, qu'il n'y a pas de nouveaux types d'objets à rajouter. Ce qui revient à dire que l'interface du visiteur abstrait doit être stable. Donc, la limite était bien perçue et expliquée dans le bouquin.

Citation:

---

Envoyé par 3DArchi

Salut Emmanuel,
C'est clairement un article intéressant dès que l'on parle de visiteur.
Ceci dit, j'ai récemment relu la partie consacrée aux visiteurs du DP des GoF. Et quelque part, il me semble qu'ils étaient conscients du problème. Ils disent bien que le DP visiteur, du fait de l'absence de double dispatch, n'est à mettre en œuvre que lorsque la structure des objets à visiter sont stables. Donc, à priori, qu'il n'y a pas de nouveaux types d'objets à rajouter. Ce qui revient à dire que l'interface du visiteur abstrait doit être stable. Donc, la limite était bien perçue et expliquée dans le bouquin.

---

'Zact. Ca fait longtemps que je ne l'ai pas ouvert moi-même. Ceci dit, cette limitation est étonnamment restrictive étant donné la nature même du pattern visiteur (le fait de l'intégrer dans une hiérarchie de classe suppose que cette hiérarchie est ouverte à l'extension, hors le pattern lui même ne l'est pas).

Le visiteur acyclique de R.C.Martin est (selon moi) à conseiller - d'autant plus qu'il n'a pas plus de problèmes de performance qu'un système ou le multi-dispatch serait implémenté nativement puisque les décisions de dispatch liées au type dynamique sont nécessairement prise au runtime, ce qui est émulé grâce au dynamic_cast<>).

Ceci dit, c'est mon opinion :)

Un cas très intéressant d'application du pattern version GoF est le cas ou les instances à visiter sont définies à l'extérieur de l'application, par exemple par des scripts. Dans ce cas, la hiérarchie qui doit être visitée par les différents visiteurs est définie au préalable sans pour autant que cela n'empêche de l'étendre. Mais ça reste quand même un cas particulier qui, en pratique, reste rare.