Editions ENI Livres | Vidéos | e-Formations
Le design pattern Visitor
Description
Le design pattern Visitor définit 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 28.1 qui décrit les clients de notre système organisés sous la forme d’objets composés selon le design pattern Composite. À l’exception de la méthode ajouteFiliale spécifique à la gestion de la composition, les deux sous-classes possèdent deux méthodes de même nom : calculeCoutEntretien et envoieEmailCommercial. Chacune de ces méthodes correspond à une même fonctionnalité dont l’implémentation est bien sûr adaptée en fonction de la classe. De nombreuses autres fonctionnalités pourraient également être implémenté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 design pattern Composite.
Cette approche est utilisable tant que le nombre de fonctionnalités reste faible. En revanche, si celui-ci devient plus important, nous obtenons alors des classes contenant beaucoup de méthodes, difficiles à maintenir. De surcroît, ces fonctionnalités donnent lieu à des méthodes calculeCoutEntretien et envoieEmailCommercial sans lien entre elles et sans lien avec le cœur des objets à la différence...
Structure
1. Diagramme de classes
La figure 28.3 détaille la structure générique du design pattern Visitor.
Figure 28.3 - Structure du design pattern Visitor
2. Participants
Les participants au design pattern Visitor sont les suivants :
-
Visiteur (VisiteurInterface) est l’interface qui contient 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 (VisiteurCalculeCoûtEntretien et VisiteurMailingCommercial) implémentent les méthodes qui réalisent la fonctionnalité correspondant à la classe.
-
Element (AbstractSociete) est une classe abstraite surclasse des classes d’éléments. Elle contient la méthode abstraite accepteVisiteur qui prend un visiteur comme argument.
-
ÉlémentConcret1 et ÉlémentConcret2 (SocieteSansFiliale et SocieteMere) implémentent 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.
L’élément...
Domaines d’application
Le design pattern Visitor 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ède 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 design pattern Visitor n’est pas adapté. En effet, toute modification de la structure implique une modification de chaque visiteur, ce qui peut s’avérer coûteux.
Exemple en PHP
Nous reprenons l’exemple de la figure 28.2. La classe AbstractSociete est décrite en PHP comme suit. La méthode accepteVisiteur est abstraite car son code dépendra de la sous-classe qui l’implémente.
<?php
declare(strict_types=1);
namespace ENI\DesignPatterns\Visitor;
abstract class AbstractSociete
{
protected string $nom;
protected string $email;
protected string $adresse;
public function __construct(string $nom, string $email, string
$adresse)
{
$this->nom = $nom;
$this->email = $email;
$this->adresse = $adresse;
}
public function getNom(): string
{
return $this->nom;
}
protected function setNom(string $nom): void
{
$this->nom = $nom;
}
public function getEmail(): string
{
return $this->email;
}
protected function setEmail(string $email): void
{
$this->email = $email;
}
public function getAdresse(): string
{
return $this->adresse;
}
protected function setAdresse(string $adresse): void
{
$this->adresse = $adresse; ...