Blog ENI : Toute la veille numérique !
🐠 -25€ dès 75€ 
+ 7 jours d'accès à la Bibliothèque Numérique ENI. Cliquez ici
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Design Patterns en C#
  3. Le pattern Visitor
Extrait - Design Patterns en C# Les 23 modèles de conception : descriptions et solutions illustrées en UML 2 et C# [3e édition]
Extraits du livre
Design Patterns en C# Les 23 modèles de conception : descriptions et solutions illustrées en UML 2 et C# [3e édition]
1 avis
Revenir à la page d'achat du livre

Le pattern Visitor

Description

Le pattern Visitor construit une opération à réaliser sur les éléments d’un ensemble d’objets. De nouvelles opérations peuvent ainsi être ajoutées sans modifier les classes de ces objets.

Exemple

Considérons la figure 4-12.1 qui décrit les clients de notre système organisés sous la forme d’objets composés selon le pattern Composite. À l’exception de la méthode ajouteFililale spécifique à la gestion de la composition, les deux sous-classes possèdent deux méthodes de même nom : calculeCoûtEntretien et envoieEmailCommercial. Chacune de ces méthodes correspond à une même fonctionnalité mais dont l’implantation est bien sûr adaptée en fonction de la classe. De nombreuses autres fonctionnalités pourraient également être implantées comme par exemple, le calcul du chiffre d’affaires d’un client (filiales incluses ou non), etc.

Sur le diagramme, le calcul du coût de l’entretien n’est pas détaillé. Le détail se trouve dans le chapitre consacré au pattern Composite.

Cette approche est utilisable tant que le nombre de fonctionnalités reste faible. En revanche, si celui-ci devient important, nous obtenons alors des classes contenant beaucoup de méthodes, difficiles à appréhender et à maintenir. De surcroît, ces fonctionnalités donnent lieu à des méthodes (calculeCoûtEntretien et envoieEmailCommercial) sans lien entre elles et sans lien avec le cœur...

Structure

1. Diagramme de classes

La figure 4-12.3 détaille la structure générique du pattern.

images/2figure28-3.png

Figure 4-12.3 - Structure du pattern Visitor

2. Participants

Les participants au pattern sont les suivants :

  • Visiteur est l’interface qui introduit la signature des méthodes qui réalisent une fonctionnalité au sein d’un ensemble de classes. Il existe une méthode par classe qui reçoit comme argument une instance de cette classe.

  • VisiteurConcret1 et VisiteurConcret2 (VisiteurCalcule-CoûtEntretien et VisiteurMailingCommercial) implantent les méthodes qui réalisent la fonctionnalité correspondant à la classe.

  • Élément (Société) est une classe abstraite surclasse des classes d’éléments. Elle introduit la méthode abstraite accepteVisiteur qui accepte un visiteur comme argument.

  • ÉlémentConcret1 et ÉlémentConcret2 (SociétéSansFiliale et SociétéMère) implantent la méthode accepteVisiteur qui consiste à rappeler le visiteur au travers de la méthode correspondant à la classe.

3. Collaborations

Un client qui utilise un visiteur doit d’abord le créer comme instance de la classe de son choix puis le transmettre comme argument de la méthode accepteVisiteur d’un ensemble d’éléments....

Domaines d’application

Le pattern est utilisé dans les cas suivants :

  • De nombreuses fonctionnalités doivent être ajoutées à un ensemble de classes sans que ces ajouts viennent alourdir ces classes.

  • Un ensemble de classes possèdent une structure fixe et il est nécessaire de leur adjoindre des fonctionnalités sans modifier leur interface.

Si la structure de l’ensemble des classes auxquelles il est nécessaire d’adjoindre des fonctionnalités change souvent, le pattern Visitor n’est pas adapté. En effet, toute modification de la structure implique une modification de chaque visiteur, ce qui peut coûter cher.

Exemple en C#

Nous reprenons l’exemple de la figure 4-12.2. La classe Societe est décrite en C# comme suit. La méthode accepteVisiteur est abstraite car son code dépend de la sous-classe.

using System; 
 
public abstract class Societe 
{ 
   public string nom { get; protected set; } 
   public string email { get; protected set; } 
   public string adresse { get; protected set; } 
 
   public Societe(string nom, string email, string adresse) 
   { 
       this.nom = nom; 
       this.email = email; 
       this.adresse = adresse; 
   } 
 
   public abstract bool ajouteFiliale(Societe filiale); 
 
   public abstract void accepteVisiteur(Visiteur visiteur); 
} 

Le code source de la sous-classe SocieteSansFiliale est le suivant. La méthode accepteVisiteur rappelle la méthode visite du visiteur.

using System; 
 
public class SocieteSansFiliale : Societe 
{ 
 public SocieteSansFiliale(string nom, string email, 
   string adresse) : base(nom, email, adresse){} 
 
 public override void accepteVisiteur(Visiteur visiteur) 
 { 
   visiteur.visite(this); 
 } 
 
 public override bool ajouteFiliale(Societe...