Discussion :

[Dalini71]

Bonjour à tous,

Si j'ai bien compris le DP Visiteur, il s'agit de séparer la déclaration d'un objet et les opérations sur celui-ci (évitant donc d'avoir une classe avec plein de méthodes).

Donc imaginons que j'ai une classe labyrinthe et que je souhaite pouvoir générer un labyrinthe aléatoirement et le résoudre.

Serait-ce une bonne idée d'avoir 2 visiteurs "VisitorGenererLabyrinthe" et "VisitorResoudreLabyrinthe" ou est ce que c'est comme prendre un bazooka pour tuer une mouche ?

En admettant qu'implémenter ces visiteurs soit une bonne idee, en C++, faut-il déclarer les classes visiteurs amies ?

Merci d'avance pour vos réponses.

[Luckyluke34]

Bonjour,

En fait c'est un peu plus compliqué que ça : le design pattern Visiteur permet de déporter hors d'une classe un certain nombre d'opérations (donc de méthodes) qui alourdissent et embrouillent une classe car elles ne sont pas forcément naturellement de la responsabilité cette classe.

Plus particulièrement, Visiteur est souvent utilisé dans un contexte où doit gérer une matrice de correspondances entre 2 dimensions fonctionnelles d'une application.

Ex fictif : il existe une série de classes dérivant de OperatingSystem (UnixBasedOperatingSystem, WindowsBasedOperatingSystem...). On veut gérer la communication de ces OS avec divers modèles d'imprimantes. Mettre dans la classe OperatingSystem autant de méthodes Print() qu'il y a de modèles d'imprimante et les surcharger au niveau de chaque classe OS fille va réellement "plomber" ces classes.

• L'idée est tout d'abord de gérer les opérations d'impression dans une classe à part. En effet un OperatingSystem n'a pas vraiment comme coeur de responsabilité d'imprimer et on respectera mieux le Single Responsibility Principle en déportant les tâches d'impression dans une classe séparée.
  
• Ensuite, il nous faut gérer toutes les combinaisons, c'est à dire la matrice de correspondances, entre les OS et les modèles d'imprimante.

=> Pour cela, on va par exemple créer une interface IPrinterVisitor et autant d'implémentations concrètes de visiteurs qu'il y a de modèles d'imprimantes (HP999PrinterVisitor, Lexmark12445PrinterVisitor...). Chaque visiteur va avoir une méthode Visit() par sous-classe d'OperatingSystem qui va déterminer ce qui se passe pour cet OS. Et chaque OS aura une méthode Accept(IPrinterVisitor visitor) qui va appeler visitor.Visit(this) et permettre au visiteur de se configurer selon le bon OS.

L'exemple est un peu moyen mais c'est l'idée ^^

Au niveau technique, le design pattern Visiteur est un des seuls moyens de réaliser cette matrice de correspondances entre 2 arborescences de classes l'absence de double dispatch dans la plupart des langages orientés objet.

[Dalini71]

Merci de ta réponse,

J'en déduit donc que pour mon cas le DP Visiteur n'est pas tout indiqué et que je ferais mieux de passer par des méthodes toutes bêtes.

[Luckyluke34]

Si tu prévois d'ajouter plus tard toute une gamme de comportements autour du labyrinthe en plus de le générer et de le résoudre, Visitor peut être utile car il va t'aider à respecter le principe ouvert/fermé : tu pourras ajouter des comportements à l'envi sans toucher à la classe Labyrinthe.

Maintenant il sera toujours temps de refactorer quand ce besoin apparaitra, donc pour l'instant en effet je n'utiliserais pas de Visitors (surtout que la responsabilité de générer un labyrinthe semble plutôt encourager l'utilisation d'un pattern Factory).

[Dalini71]

Ok je commence à y voir un peu plus claire maintenant, merci beaucoup pour ton aide, je vais aller voir du côté du DP Factory