Patron de conception Visitor Injector en Java, un patron et tutoriel de Yann Caron

Bonjour à tous,

Je vous propose un tutoriel Java intitulé "Tutoriel architectural sur le patron de conception visiteur par injection (ou Visitor Injector)".
Ce patron de conception vise à contourner le caractère statique du patron Visiteur du Gang of Four par injection de dépendance. L'idée m'en est venue lorsque j'ai réalisé l'analyseur syntaxique que j'ai nommé JASI (qui sera l'objet d'une ouverture des sources très prochainement).

Pour séparer la syntaxe (l'AST) de l'implémentation (la sémantique), la plupart des parseurs proposent une solution toute trouvée par le Gang Of four : le patron Visiteur. Or celui-ci contient une méthode de visite pour chaque Classe de l'AST. Si, à posteriori, une classe venait à être ajoutée au modèle, la définition du visiteur devrait être modifiée. Dans le cas d'une architecture à plusieurs niveaux, celui-ci devrait être surclassé pour accepter de nouvelles méthodes de visite. Cela engendre des transtypages et des teste de types peu élégants.

Terrence Parr lui-même propose une solution de contournement dans son livre : Language Implementation Patterns: Create Your Own Domain-Specific and General Programming Languages. Il y expose un visiteur dans lequel le test de type est effectué lors du parcours en profondeur de l'arbre.

Grace à ce patron, je propose une solution plus en amont du problème. Le visiteur ne définit plus qu'une méthode générique à tous les types de l'AST. Un tableau associatif (Map en Java) référence toutes les associations Class / Visiteur, et, lors d'un parcours en profondeur préliminaire, les visiteurs associés sont "injecté" aux ASTs traversés. La suite reste inchangée si ce n'est que lors du parcours ce sont les visiteurs injecté qui sont appelés.

Tout est détaillé ici, suivez le guide ;-)

Bonjour,

Si j'ai bien compris votre proposition, il s'agit d'ajouter un niveau d'indirection (via la classe VisitorInjector et l'injection) pour choisir le bon visiteur. Je ne comprends pas l'intérêt de faire deux parcours : pourquoi l'injection n'est pas faite juste avant l'exécution dans un seul parcours ?

Merci pour votre réponse

C'est tout à fait ça Tlemeu.

La phase d'indirection est faite dans un premier parcours pour ne pas pénaliser les performances du second.
En effet, dans le cas d'un interpréteur (AST / Visitor) le choix du visiteur ce retrouverait lors de l'exécution du programme (runtime).

De plus cela permet de découpler les responsabilité en deux phases, une d'indirection (le choix du comportement) et l'autre d'exécution (l'utilisation du comportement).
Enfin, il n'est pas rare de parcourir plusieurs fois les même nœuds dans ce genre de problématique. De ce fait, il faudrait à chaque fois tester si le visiteur a déjà été choisi ou non (par lazy initialization). Cela rajoute encore des testes.

Mais ta remarque est pertinente.