Visitor

Problem

Stell dir vor du hasst eine grosse Collection mit verschiedenen Objekttypen, die Standorte wie Städte, Museen, Sehenswürdigkeiten und ähnliches beinhalten. Du sollst jetzt diese Collection als XML exportieren. Klingt eigentlich nicht sehr schwierig, nur soll der Code dazu nicht in den Klassen implementiert werden, damit dort keine Fehler eingebaut werden und sich die Klassen nur um ihre Geodaten kümmern sollen.

Lösung

Um das Problem zu Lösen gibt es das Visitor Pattern. Dieses Pattern schlägt vor das Verhalten für diesen XML Export in eine separate Visitor Klasse auszulagern anstelle der existierenden Klasse. Das Objekt, dass dann das Verhalten aufrufen soll, wird als Argument beim Aufruf mitgegeben.

Im Visitor wird dann pro Klasse die übergeben werden kann, eine Methode erstellt, welche an die Eigenschaften der Klasse angepasst ist. Damit dann aber beim Durchlauf durch die Collection mit einer einzelnen Methode gearbeitet werden kann, erhält jede dieser Klassen eine Methode um den Visitor zu akzeptieren. Double Dispatch

UML Diagramm

Vorteile

• Grundsatz der Einzelverantwortung. Code, der dasselbe Verhalten für mehrere Klassen implementiert ist in einer eigenen Klasse zusammengefasst.

• Open/Closed-Prinzip. Den Klassen kann neues Verhalten hinzugefügt werden, ohne die Klassen selbst zu verändern

• Ein Visitor kann nützliche Informationen von verschiedenen Objekten sammeln. Das ist vor allem praktisch wenn Daten aus komplexen Objektstrukturen, wie Objekt Trees, gesammelt werden sollen.

Nachteile

• Die Visitoren müssen jedesmal angepasst werden, wenn sie mit neuen Klassen arbeiten soll oder Klassen entfernt werden.