Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 5 sur 5
  1. #1
    Membre confirmé Avatar de Dalini71
    Homme Profil pro Jérémy
    Étudiant
    Inscrit en
    février 2008
    Messages
    176
    Détails du profil
    Informations personnelles :
    Nom : Homme Jérémy
    Âge : 27
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2008
    Messages : 176
    Points : 271
    Points
    271

    Par défaut Générer et résoudre un labyrinthe

    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.

  2. #2
    Membre émérite
    Inscrit en
    janvier 2011
    Messages
    284
    Détails du profil
    Informations forums :
    Inscription : janvier 2011
    Messages : 284
    Points : 837
    Points
    837

    Par défaut

    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.

  3. #3
    Membre confirmé Avatar de Dalini71
    Homme Profil pro Jérémy
    Étudiant
    Inscrit en
    février 2008
    Messages
    176
    Détails du profil
    Informations personnelles :
    Nom : Homme Jérémy
    Âge : 27
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2008
    Messages : 176
    Points : 271
    Points
    271

    Par défaut

    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.

  4. #4
    Membre émérite
    Inscrit en
    janvier 2011
    Messages
    284
    Détails du profil
    Informations forums :
    Inscription : janvier 2011
    Messages : 284
    Points : 837
    Points
    837

    Par défaut

    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).

  5. #5
    Membre confirmé Avatar de Dalini71
    Homme Profil pro Jérémy
    Étudiant
    Inscrit en
    février 2008
    Messages
    176
    Détails du profil
    Informations personnelles :
    Nom : Homme Jérémy
    Âge : 27
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2008
    Messages : 176
    Points : 271
    Points
    271

    Par défaut

    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

+ Répondre à la discussion
Cette discussion est résolue.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •