Discussion :

[f56bre]

Bonjour à tous,

J'étais sur le point d'utiliser la version acyclique du design pattern visitor (la version générique proposée par alexandrescu dans "Modern C++ Design-Generic Programming and Design Patterns Applied") cependant comme il ne me convient pas à 100% je cherche quand même une implémentation alternative.

Avec la version d'alexandrescu (et d'ailleurs avec la plupart des implémentation du DP visitor) je fais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

maClasse->Accept(monVisitor);

La problématique étant d'appeler le bon visiteur sur la classe malgré l'utilisation du polymorphisme et la résolution statique des paramètres de fonction.

Je me demandais donc si je pouvais me passer du double dispatching en récupérant le bon visiteur via une factory, ie. en demandant à l'instance maClasse un identifiant (ex un string donnant le nom de sa classe) qui serait associé dans une std::map à un visiteur.

En fait ma question n'est pas tant de savoir si c'est faisable mais plutôt si selon vous c'est valable d'un point de vue temps de traitement par rapport au DP visitor acylique qui fait un dynamic_cast et utilise le double dispatching (=> plusieurs appels de fonctions)?

D'avance merci

[koala01]

Salut,

Une chose est sure, c'est qu'il n'est vraiment pas intéressant d'utiliser une comparaison de chaine de caractères pour travailler: c'est une comparaison qui prend énormément de temps (car, si le seul caractère différent entre deux chaines est le dernier, la comparaison passera par... tous les caractères)

Une deuxième chose qui est sure, c'est que, si tu veux éviter le double dispatch, tu en arrivera à une situation "bancale" dans laquelle:

1. tu donnera trop de responsabilité à ta classe "visitée"
2. tu introduira des dépendances importantes et "mal venues" entre ta classe "visitée" et la classe "visiteuse"
3. tu multipliera les fonctions dans la classe "visitée", avec, comme résultat, l'obligation de modifier toute la hiérarchie si, d'aventure, tu veux rajouter une manière de la visiter supplémentaire, en contradiction complète avec le principe "Open closed code" (un code doit être "ouvert" à l'évolution, mais "fermé" à la modification)

Bref, tu l'auras compris: il serait possible d'envisager quelque chose, mais cela me choque à ce point que je n'ai pas envie d'en parler

[f56bre]

Merci pour ta réponse koala01 mais je ne vois pas pourquoi ma proposition d'implémentation va entraîner les 3 défauts que tu cite.
En effet, mon but est tout le contraire c'est à dire que ma classe visitée ne sache même pas qu'elle va l'être et donc par suite ne connaisse rien de son(ses) visiteur(s).
Pour moi ça se déroulerait comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
MaClasseVisitee mcv;
maFactoryDeVisiteur.visite(mcv);

et au sein de la fonction "visite()" on aurait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
std::string id = classeVisitee.getId();
//création d'une instance du visiteur adéquate via une map associant les identifiants et les visiteurs
//Visite de la classe

Ma classe visitée n'a donc nulle besoin d'implémenter la fonction "accept()" et ne connait rien de la classe qui la visite.