In diesem Beitrag beschreibe ich ein Designmuster namens „Besucher“. oder „Besucher“
Dieses Muster gehört zur Gruppe der Verhaltensmuster.
Lass uns ein Problem finden
Dieses Muster wird hauptsächlich verwendet, um die Beschränkung des Einzelversands in Sprachen mit früher Bindung zu umgehen.
Alice X von NFGPhoto (CC-2.0)
Lassen Sie uns eine abstrakte Klasse/ein abstraktes Protokoll Band erstellen, eine Unterklasse von MurpleDeep erstellen und eine Besucherklasse mit zwei Methoden erstellen – Eine für die Ausgabe aller Nachkommen von Band an die Konsole, die zweite für die Ausgabe von MurpleDeep. Hauptsache, die Namen (Signaturen) der Methoden sind gleich und die Argumente unterscheiden sich nur je nach Klasse. Mithilfe der Zwischenausdruckmethode mit dem Band-Argument erstellen wir eine Instanz von Visitor und rufen die Visit-Methode für MurpleDeep auf.
Unten ist der Code in Kotlin:
Die Ausgabe lautet: „Dies ist die Band-Klasse“
Wie ist das möglich?!
Warum das passiert, wird in vielen Artikeln mit klugen Worten beschrieben, auch auf Russisch, aber ich schlage vor, Sie stellen sich vor, wie der Compiler den Code sieht, vielleicht wird alles sofort klar:
Das Problem lösen
Es gibt viele Lösungen, um dieses Problem zu lösen. Als nächstes betrachten wir eine Lösung, die das Besuchermuster verwendet.
Wir fügen der abstrakten Klasse/dem abstrakten Protokoll die Methode „accept“ mit dem Argument „Visitor“ hinzu, rufen „visitator.visit(this)“ innerhalb der Methode auf und fügen dann eine Überschreibung/Implementierung der Methode „accept“ zur Klasse „MurpleDeep“ hinzu, wodurch wir wiederum entschieden und ruhig gegen DRY verstoßen Besucher.visit(this).< br />Endgültiger Code:
Quellen
https://refactoring.guru/ru/ design-patterns/visitor-double-dispatch
Quellcode
https://gitlab.com/demensdeum/patterns
