Ces dernières années, l’importance de la programmation orientée objet (POO), une sous-forme du paradigme de programmation impérative, n’a cessé de croître. Par rapport à d’autres styles de programmation, l’option qui consiste à décrire tous les modules d’un projet logiciel comme un objet, dont le comportement peut être défini par des classes correspondantes, présente plusieurs avantages décisifs. Pour de nombreux développeurs, la possibilité de réutiliser facilement des parties du programme déjà conçues est un argument évident en faveur de l’utilisation d’une POO.
Pour faciliter encore la réutilisabilité ainsi que l’implémentation, l’adaptabilité et la testabilité des objets intégrés, quatre informaticiens ont publié les patrons de conception GoF dans l’ouvrage « Design Patterns: Elements of Reusable Object-Oriented Software ». Parmi cette vingtaine de patrons de conception, on trouve le Visitor pattern ou Visitor design pattern (en français : patron de conception Visiteur) que nous détaillons pour vous dans les paragraphes suivants.
Le Visitor design pattern, abrégé en Visitor pattern, fournit une solution pour séparer un algorithme de la structure de l’objet sur lequel il travaille. Il décrit une méthode pour ajouter de nouvelles opérations à des structures d’objets existantes sans que ces structures aient besoin d’être modifiées. Grâce à cette caractéristique, le Visitor pattern peut être utilisé pour mettre en œuvre le principe ouvert/fermé. Ce principe du développement logiciel orienté objet repose sur le fait que chaque unité d’un logiciel – telles que les modules, les classes ou les méthodes – est à la fois ouverte (open) aux extensions et fermée (closed) aux modifications.
En français, on désigne également le Visitor Pattern sous les termes « patron de conception Visiteur » ou « patron Visiteur ».
Le Visitor pattern est l’un des 23 patrons de conception (catégorie : patron comportemental) décrits et publiés en 1994 par les informaticiens Erich Gamma, Richard Helm, Ralph Johnson et John Vlissides. Ces quatre informaticiens étant connus sous le nom de « Gang of Four » (fr. bande de quatre ; GoF), l’appellation patrons de conception GoF s’est établie pour désigner ces design patterns.
Lorsque la structure de l’objet est composée de nombreuses classes et que de nouvelles opérations sont souvent nécessaires, il est très laborieux pour les développeurs de devoir implémenter une nouvelle sous-classe pour chaque nouvelle opération. En procédant de la sorte, le système obtenu disposerait de différentes classes de nœud qui seraient non seulement trop compliquées à comprendre mais aussi à entretenir et à modifier. L’instance décisive du Visitor pattern, le visiteur (Visitor), permet d’ajouter de nouvelles fonctionnalités virtuelles à une famille de classes sans avoir à les modifier.
Les fonctionnalités ou les méthodes virtuelles définissent les fonctionnalités cibles à exécuter dont le but n’a pas à être connu au moment de la compilation. Il s’agit d’un outil essentiel des langages orientés objet.
Le patron de conception Visiteur prévoit une définition séparée de l’objet visiteur dans l’idée d’implémenter une opération qui sera exécutée sur un ou plusieurs éléments de la structure de l’objet. Les clients accédant à la structure de l’objet appellent ensuite des méthodes (par ex. « accept(visitor) ») sur l’élément concerné. Ces méthodes délèguent la requête à l’objet visiteur accepté qui peut ensuite exécuter l’opération concernée.
La façon la plus simple d’illustrer l’interaction entre les éléments existants et les objets visiteurs intégrés selon le Visitor pattern est d’utiliser une représentation graphique des relations et des processus d’un potentiel logiciel orienté objet. Très apprécié, le langage de modélisation UML (Unified Modeling Language) est idéal pour cela. C’est la raison pour laquelle nous l’avons utilisé dans le diagramme de classes suivant représentant le Visitor pattern.
Le Visitor pattern constitue un moyen éprouvé et efficace d’étendre les unités existantes d’un logiciel orienté objet. Une nouvelle opération peut facilement être ajoutée en définissant un nouveau visiteur. Cette méthode permet d’ailleurs également de centraliser le code fonctionnel : l’implémentation correspondant à une opération est centralisée dans la classe visiteur et n’a pas à être complétée dans les autres classes individuelles. Pour faire simple, l’avantage décisif d’un logiciel conçu selon le Visitor pattern réside dans le fait que le code source des objets utilisés n’a pas à être constamment ajusté. À la place, la logique est répartie entre les visiteurs, agissant comme des remplaçants, et les classes de visiteurs.
Il va de soi que le patron de conception Visiteur n’est pas irréprochable. En adoptant les principes de ce patron, les développeurs doivent être conscients des éléments suivants : toutes les modifications apportées à la classe d’un élément, même les plus petites, entraînent généralement un ajustement des classes visiteurs affectées. Par ailleurs, ce patron n’évite pas le travail supplémentaire nécessaire pour introduire de nouveaux éléments a posteriori puisqu’il faudra également implémenter pour ces éléments des méthodes visit() qui devront à leur tour être ajoutées dans les classes ConcreteVisitor. La remarquable modularité des unités logicielles n’est donc pas obtenue sans efforts.
Le Visitor pattern peut considérablement simplifier les tâches récurrentes en développement logiciel. Il est intéressant de se pencher de plus près sur ce patron de conception, en particulier pour les développeurs suivant le paradigme de la programmation orientée objet. Depuis sa présentation en 1994, ce patron est parvenu à s’imposer dans le milieu de la programmation, le type de projet logiciel ne jouant en principe aucun rôle décisif dans l’utilité de ce patron. En ce qui concerne les langages de programmation pouvant en bénéficier, il n’existe en principe aucune restriction concrète pour ce patron, si ce n’est qu’il est tout particulièrement adapté au paradigme orienté objet.
Le Visitor pattern joue notamment un rôle fondamental dans les langages suivants :
Afin de protéger votre vie privée, la vidéo ne se chargera qu'après votre clic.
D’un point de vue extérieur, il n’est pas toujours simple de comprendre l’utilisation et l’utilité du Visitor pattern. De nos jours, toute personne souhaitant apprendre la programmation sera pourtant confrontée à ce patron et à sa mise en œuvre.
Pour expliquer le patron de conception Visiteur, on utilise souvent une analogie facile à comprendre, celle du trajet en taxi : un client réserve un taxi qui peut venir le prendre au pas de sa porte. Lorsque la personne est assise dans le taxi, « qui lui rend visite », le taxi (ou son conducteur) dispose d’un contrôle total sur le transport de la personne.
L’analogie des achats dans un supermarché est elle aussi souvent utilisée pour expliquer le fonctionnement du Visitor pattern : dans son caddy, la personne réalisant les achats rassemble les articles qu’elle désire. Ces achats représentent l’ensemble des éléments de la structure de l’objet. Une fois à la caisse, le caissier tient le rôle du visiteur scannant les prix et le poids des différents articles (ou éléments) afin de calculer le coût total à payer.
Pour finir, le code suivant présente une mise en œuvre simple et basique du Visitor pattern en PHP.
return ‘B’;
}
public function getData() {
return $this->the_data;
}
public function accepter(visiteur $visiteur) {
$visiteur->VisiteDeLElementB($this);
}
}
abstract class visiteur {
abstract function VisiteDeLElementA(ElementA $elem);
abstract function VisiteDeLElementB(ElementB $elem);
}
class visiteur1 extends visiteur{
private $characteristics;
public function getCharacs() {
return $this->characteristics;
}
public function VisiteDeLElementA(ElementA $elem) {
$this->characteristics = ‘Info:’.$elem->getInfo();
}
public function VisiteDeLElementB(ElementB $elem) {
$this->characteristics = ‘DATA:’.$elem->getData().’!!’;
}
}
function Test() {
write_line(‘début du test’);
// Structure de l’objet
$elemente = array (
new ElementA(‘Bonjour’, ‘Nouveau !!’),
new ElementB(‘Enfin.’),
);
$bes1 = new visiteur1();
foreach ($elemente as $element) {
$element->accepter($vis1);
write_line(‘Après la visite de l’élément’.$element->getName().’: ‘.$bes1- >getCharacs());
}
}
function write_line($text) {
print $text.’<br>‘;
}
Test();L’extrait de code ressemble alors à ce qui suit :
Début du test
Après la visite de l’élément A : Info:[Bonjour--Nouveau !!]
Après la visite de l’élément B : DATA:(Enfin.)!!
Si vous avez déjà eu affaire à des méthodes de travail modernes, vous avez sûrement déjà rencontré la notion de « développement agile ». Pourtant, la plupart des gens ne savent pas très bien ce qu’elle recouvre. Une des raisons en est que l’agilité dans le développement de logiciels se refuse délibérément à toute définition trop rigide et reste très englobante. Nous tentons de vous faire...
L’Observer design pattern, abrégé en Observer pattern, est l’approche de développement adaptée si de très nombreux objets ont besoin d’informations sur le statut actuel d’un autre objet. Dans ce concept, toutes les modifications sont automatiquement transmises par l’objet observé. Quel est le fonctionnement exact et pour quels logiciels les patrons de conception Observateur sont-ils adaptés ?
La gestion des classes pose régulièrement de plus grands défis aux développeurs, surtout lorsque le nombre de sous-classes concernées est en augmentation. Le « Decorator pattern » promet une solution : l’approche de conception permet une adaptation et une extension dynamiques des classes, que ce soit pendant la compilation ou lors de l’exécution du logiciel.
Si les mêmes séquences de programme non modifiables sont toujours utilisées, le singleton Pattern entre en jeu. Le singleton garantit qu’une classe n’existe qu’une seule fois. Il appartient à la catégorie des patrons de conception pour la programmation orientée objet. Le singleton pattern est considéré comme un outil puissant mais problématique.
Offrez un service performant et fiable à vos clients avec l'hébergement web de IONOS.
