Dans cet article, je décrirai un modèle de conception appelé « Visiteur » ; ou “Visiteur”
Ce modèle appartient au groupe des Modèles comportementaux.
Trouvons un problème
Ce modèle est principalement utilisé pour contourner la limitation de l’envoi unique dans les langues à liaison précoce.
Alice X par NFGPhoto (CC-2.0)
Créons une classe/protocole abstrait Band, créons une sous-classe de MurpleDeep, créons une classe Visitor avec deux méthodes – un pour afficher n’importe quel descendant de Band sur la console, le second pour afficher n’importe quel MurpleDeep, l’essentiel est que les noms (signatures) des méthodes soient les mêmes et que les arguments ne diffèrent que par classe. En utilisant la méthode d’impression intermédiaire avec l’argument Band, nous créons une instance de Visitor et appelons la méthode de visite pour MurpleDeep.
Vous trouverez ci-dessous le code en Kotlin :
Le résultat sera “Ceci est la classe Band“
Comment est-ce possible ?!
La raison pour laquelle cela se produit est décrite avec des mots intelligents dans de nombreux articles, y compris en russe, mais je vous suggère d’imaginer comment le compilateur voit le code, peut-être que tout deviendra clair tout de suite :
Résoudre le problème
Il existe de nombreuses solutions pour résoudre ce problème. Nous examinerons ensuite une solution utilisant le modèle Visiteur.
Nous ajoutons la méthode accept avec l’argument Visitor à la classe/protocole abstrait, appelons Visitors.visit(this) à l’intérieur de la méthode, puis ajoutons une substitution/implémentation de la méthode accept à la classe MurpleDeep, violant de manière décisive et calme DRY, en écrivant à nouveau visiteur.visit(this).< br />Code final :
Sources
https://refactoring.guru/ru/ modèles de conception/double expédition des visiteurs
Code source
https://gitlab.com/demensdeum/patterns
