Das C# Beispiel betrachte ich mal als gutes Beispiel, wie man es nicht machen sollte. Nur weil C# davor steht, ist der Code ja nicht automatisch über jeden Zweifel erhaben.
Da hast du natürlich Recht. Ist halt die Version die ich üblicherweise kenne, bin aber gerne bereit was zu lernen.
Was ist denn der praktische Vorteil deiner Lösung, also was "So solltest die niemals t.Accept(Visitor) aufrufen, sondern immer Visitor.Visit(t)" angeht? Inwiefern entkoppelt es mehr da man sich ja in beiden Fällen auf eine abstrakte Klasse/Interface bezieht?
Zitat:
Mein Minimalbeispiel kann man natürlich so umschreiben, (auch wenn Interfaces jetzt unter Delphi nicht sehr praktisch sind) das ist schon klar.
Nun, ich kann nur kommentieren, was ich sehe. Da ich deine realen Anforderungen nicht kenne, kann ich dazu auch keine Vorschläge machen.
Schwer das mit wenig Code zu illustrieren. Ein Beispiel wäre das "pretty printing" eines Syntaxbaums (AST). Hierzu muss man das Einrückungslevel mitliefern, bzw. einen Präfixstring, der je nach Knoten anders ist, an die Kindknoten weiterreichen.
Hier gibt es ähnliche Fragen:
https://stackoverflow.com/questions/...h-return-value
https://stackoverflow.com/questions/...isitor-pattern
Zitat:
Aber das Ziel ist es das Visitorpattern so zu erweitern, dass man zusätzliche Parameter/Rückgabewerte haben kann.
Das Ziel geht meiner Meinung nach konträr zum ursprünglichen Anliegen des Visitor Patterns - der Entkopplung der Strukturklassen und deren Verarbeitung. Ist aber eben auch nur meine Meinung.
Deswegen will ich die Parameter ja allgemein halten.
Im Endeffekt sollte etwas wie die Lösung für Format() gut funktionieren:
procedure Accept(Visitor: TVisitor; const Args: array of const);
Den Rückgabewert könnte man dann über eine Instanz-Variable des Visitors lösen, wie in deinem Vorschlag, und auch in dem C++-Beispiel oben. Im Endeffekt ist das dann eine Art Callbackfunktion (die ja auch häufig zusätzliche "User"-Parameter haben).
Damit wäre ich eigentlich zufrieden. Bleibt die obige Frage übrig.