Le design Pattern Visiteur
L’intérêt du design pattern “Visiteur” est de séparer un algorithme des données qu’il traite. Les données traitées doivent être stockées dans des classes possédant une méthode
public void accept(Visitor v)
On peut par le même occasion définir une interface Visitable définissant cette méthode et implémenter cette interface dans toutes les classes de données.
Visitor est une interface possédant une méthode visit() pour chaque classe de données. Cette méthode est appelée par la méthode accept de chaque classe de données. Le code des méthodes accept est donc toujours le même:
public void accept(Visitor v){
v.visit(this);
}
Coder l’algorithme revient à créer une ou des classes implémentant l’interface Visitor et de définir le comportement de l’algorithme pour chaque classe de données.
Ci dessous le diagramme de classes UML d’un exemple simple d’utilisation du design pattern Visiteur
Le design pattern Visiteur peut s’avérer très pratique dès qu’il s’agit de gérer des arborescences d’objets, puisque dans ce cas il permet aussi de spécifier la manière dont les relations entre les objets doivent être parcourues. Le cas d’un algorithme de génération de code à partir d’un arbre sémantique en mémoire est un bon exemple. L’arbre sémantique du code à générer est représenté en mémoire par un arbre d’objets. Chaque élément de l’arbre est un objet d’une classe implémentant l’interface Visitable. En plus d’appeler la méthode adaquat du visiteur, la méthode accept d’un noeud de l’arbre va appeler la méthode accept de tous ces enfants dans l’ordre qui lui convient et ainsi faire avancer le parcours de l’arbre. L’objet Visiteur est ainsi propagé dans tous les éléments de l’arbre.
Le design pattern visiteur est un exemple de design pattern de délégation.