Pattern: Visitor

[implementation]

Hallo liebe Forumsgenossen,

so manch einer von euch ist sicherlich schonmal in folgende Situation geraten:

Ihr habt sehr viele Klassen, die alle eine neue gemeinsame Methode bekommen sollen, die sich aber nicht zentral im Vorfahren einfügen lässt (bspw. weil sich jede Unterklasse anders verhalten soll).
Nun könntet ihr die Methode in jeder dieser Klasse einzeln einführen. Dann hättet ihr die Methoden der jeweiligen Klasse immer schön beieinander.

Delphi-Quellcode:

type
  TClass1 = class
    procedure AndereMethode;
    procedure BlubbNochMehr;
    // ...
    procedure TuWasBesonderes;
  end;
  TClass2 = class
    procedure IchKannWas;
    procedure GanzAnderes;
    // ...
    procedure TuWasBesonderes;
  end;

// TClass1
procedure TClass1.AndereMethode;
begin
  MachWas;
  MachNochMehr;
end;
...
procedure TClass1.TuWasBesonderes;
begin
  Writeln('Ich bin Klasse 1');
end;

// TClass2
procedure TClass2.IchKannWas;
begin
  MachIrgendwas;
  GuckBloed;
end;
...
procedure TClass2.TuWasBesonderes;
begin
  Writeln('Ich bin Klasse 2');
end;

Nun könnt ihr im Nachhinein schön jede Klasse an sich überblicken.

Nun mag manchmal aber etwas anderes viel sinnvoller sein:
Wäre es nicht viel schöner, alle TuWasBesonderes() auf einmal an einer zentralen Stelle im Blick zu haben?

Die Viererbande hat sich dazu ein schönes Pattern ausgedacht: Den Visitor.

Delphi-Quellcode:

// Unit A
type
  IVisitor = interface
    procedure Visit(const x: TClass1); overload;
    procedure Visit(const x: TClass2); overload;
  end;
  TClass1 = class
    // viele Methoden...
    procedure TuWasBesonderes(const v: IVisitor);
  end;
  TClass2 = class
    // viele Methoden...
    procedure TuWasBesonderes(const v: IVisitor);
  end;

procedure TClass1.TuWasBesonderes(const v: IVisitor);
begin
  v.Visit(self);
end;

procedure TClass2.TuWasBesonderes(const v: IVisitor);
begin
  v.Visit(self);
end;

Delphi-Quellcode:

// Unit B
uses UnitA;

type
  TVisitorA = class (TInterfacedObject, IVisitor)
    procedure Visit(const x: TClass1); overload;
    procedure Visit(const x: TClass2); overload;
  end;
  TVisitorB = class (TInterfacedObject, IVisitor)
    procedure Visit(const x: TClass1); overload;
    procedure Visit(const x: TClass2); overload;
  end;

procedure TVisitorA.Visit(const x: TClass1);
begin
  Writeln('Visitor A mit Klasse 1');
end;

procedure TVisitorA.Visit(const x: TClass2);
begin
  Writeln('Visitor A mit Klasse 2');
end;

procedure TVisitorB.Visit(const x: TClass1);
begin
  Writeln('Visitor B mit Klasse 1');
end;

procedure TVisitorB.Visit(const x: TClass2);
begin
  Writeln('Visitor B mit Klasse 2');
end;

Und da können wir auch noch mehr Vorteile sehen:

• Wir können nicht nur einen Visitor schreiben, sondern gleich mehrere! Dadurch hat der Aufrufer von TuWasBesonderes() auch eine bessere Möglichkeit, den Ablauf zu beeinflussen. Neue Visitoren lassen sich schnell dazuergänzen, überlegen Sie mal, wie schnell es nun ginge, noch einen Visitor C hinzuzufügen.
• Es lassen sich auch schnell neue Klassen ergänzen. Angenommen wir führen nun eine neue Klasse 3 ein, müssen wir sie nur IVisitor.Visit() aufrufen lassen, und sie in den Visitoren ergänzen.
• Wir können damit die gesamte TuWasBesonderes()-Funktionalität in eine eigene Unit auslagern.

Mfg und in der Hoffnung, geholfen zu haben,
implementation

Kritik ist erwünscht, also scheut euch nicht ;)

[stahli]

Ok vielen Dank für die Vorlage! :thumb:

Ich habe auch hier schon des öfteren reingesehen und obwohl es deutsch beschrieben ist, wirbelt mein interner Visitor die Inhalte immer wieder durcheinander. :duck:
Irgendwie bin ich an der gleichen Stelle wie damals, als ich "objektorientierte Programmierung" verstehen wollte. :stupid:

Darf ich mal Dein Beispiel gedanklich erweitern?
Deine Klassen haben ein Value als Integer.

Dann will ich zwei Methoden Add und Del, die Value jeweils erhöhen bzw. verringern und den Wert ausgeben. In Klasse 2 analog und plus und minus 2.
Als Methode ist das ja kein Problem. Ich implementiere insgesamt 4 Methoden und fertig.

Wie macht man das mit Visitorn und was ist der Vorteil?

Und was tut man, wenn man eine Methode Change(X: Integer) als Visitor realisieren will, die Value den Parameter hinzuadiert?

[s.h.a.r.k]

Hm, an der Stelle könnte man auch mit class helper weiter kommen. Blöd an diesem Pattern finde ich, dass gewisser Code, den ich logisch in die Klasse gepackt hatte, auf einmal außerhalb befindet. Interessanter wird das Pattern erst, wenn du eine Basisklasse hast, von der n Klassen abgeleitet wurden und nicht alle n Klassen diese ein besondere TuWas() Methode kommen soll. Wobei man an dieser Stelle auch eine abstrakte Ableitung generieren könnte und die entsprechenden Klassen dann von dieser neuen abstrakten Klasse ableiten könnte.

[SebE]

Eine schöne Verwendung für den Visitor, die mir immer sofort einfällt, wenn ich einen sehe:
Man möchte seine Business-Objekte persistieren (in eine andere Form bringen, um diese ablegen zu können).
Jetzt hat man 20 Objekte, die nicht unterschiedlicher sein könnten und immer den Gendanken im Kopf, dass das Speichern von Objekten nicht Aufgabe der Objekte selbst ist.

Hier legt man sich einen Visitor an, der für das Ablegen jedes einzelnen Objektes verantwortlich ist.

[geskill]

@stahli, würde es so machen:

Delphi-Quellcode:

type
  TVisitorAddiere = class (TInterfacedObject, IVisitor)
  private
    FValue: Integer;
  public
    constructor Create(AValue: Integer);
    procedure Visit(const x: TClass1); overload;
    procedure Visit(const x: TClass2); overload;
  end;

//...

constructor TVisitorAddiere.Create(AValue: Integer);
begin
  FValue := AValue;
end;

procedure TVisitorAddiere.Visit(const x: TClass1);
begin
  x.Wert := x.Wert + FValue;
end;

procedure TVisitorAddiere.Visit(const x: TClass2);
begin
  x.Wert := x.Wert + FValue;
end;

Beispielaufruf:

Delphi-Quellcode:

var
  VisitorAddiere: TVisitorAddiere;

begin
  VisitorAddiere := TVisitorAddiere.Create(100); // wenn man 102 addieren will muss man eben neuen VisitorAddiere erstellen mit Parameter 102

  Class1.TuWasBesonderes(VisitorAddiere);

  VisitorAddiere.Free;
end;

[stahli]

@shark
class helper würde ich nur alt "Notlösung" ansehen. Sofern man eigene Klassen definiert sollte man m.E. darauf verzichten.

@SebE
Dafür kann man aber noch einfacher einen Serialisierer (Prozedur oder Klasse) nutzen, dem man die Objekte zum Speichern übergibt. M.E. hätte man damit das selbe Ergebnis.

@geskill
So etwa hatte ich mir das gedacht. Man erzeugt also ein VisitorObjekt (VO), definiert beliebige Eigenschaften, übergibt es dann dem Objekt (O), das dann VO.Visit(O) aufruft, wo Eigenschaften in O und VO geändert werden können. Vor dem anschließenden Freigeben von VO könnte man ggf. dort noch Rückgabewerte auswerten.
Ein sinnvollerer Procedurname als "TuWasBesonderes" könnte dann wohl "Do", "DoVisit" oder "Visit" sein. Oder wie macht Ihr das üblicherweise?

Also verstanden habe ich es jetzt (mutmaßlich ;-)) - jedenfalls die Funktionsweise.

Ob es aber zu einer einfacheren Arbeitsweise beiträgt, da bin ich mir nicht sicher.

Delphi-Quellcode:

O.Add(100);

sieht erst mal einfacher aus. Und ob die Methodenauslagerung in andere Units praktisch etwas bringt, müsste man sicher eine Weile testen.

[SebE]

@stahli:
Was machst du wenn weit und breit keinen "Serialisierer" findest, der dir helfen möchte?
Selbst ist der Mann!

Es sollte nur ein Beispiel sein, welches - in meinen Augen - den Visitor perfekt in seiner Tätigkeit beschreibt.
Dass man Objekte auf 1000 verschiedenen Wegen auf die Platte bekommt, mindert den Wert meines Beispiels in keiner Weise.

Es ist ein Muster. Jeder muss selbst für sich herausfinden, ob und wofür er es verwenden möchte.

[implementation]

Soweit es so gewünscht ist, kann man den Wert ja auch der Methode einfach übergeben:

Delphi-Quellcode:

type
  TKlasse = class;
  IVisitor = interface
    procedure Visit(const x: TKlasse; const v: Integer);
  end;
  TKlasse = class
  protected
    FWert: Integer;
  public
    procedure Add(const vis: IVisitor; const val: Integer);
    property Wert: Integer read FWert write FWert;
  end;
  TVisitor = class(TInterfacedObject, IVisitor)
    procedure Visit(const x: TKlasse; const v: Integer);
  end;

procedure TKlasse.Add(const vis: IVisitor; const val: Integer);
begin
  vis.Visit(self,val);
end;

procedure TVisitor.Visit(const x: TKlasse; const val: Integer);
begin
  x.Wert := x.Wert + val;
end;

[implementation]

Zitat:

Zitat von s.h.a.r.k (Beitrag 1131117)

Blöd an diesem Pattern finde ich, dass gewisser Code, den ich logisch in die Klasse gepackt hatte, auf einmal außerhalb befindet.

Das kommt natürlich ganz auf die Situation an.
Manchen Code kann man natürlich besser bei der Klasse behalten, aber gar nicht so selten kommt es eben auch vor, dass es einfach übersichtlicher ist, wenn man bestimmte Codestellen auslagert.

[implementation]

Zitat:

Zitat von stahli (Beitrag 1131120)

Ein sinnvollerer Procedurname als "TuWasBesonderes" könnte dann wohl "Do", "DoVisit" oder "Visit" sein. Oder wie macht Ihr das üblicherweise?

Am sinnvollsten ist es natürlich, sie nach dem zu benennen, was sie machen soll ;)
"Visit" nennt man üblicherweise die Methoden des Visitors. Die Methode in der Klasse, die ich hier "TuWasBesonderes" genannt habe, heißt in der Literatur zumeist "Accept".
In der Praxis gibt man ihr aber lieber einen aussagekräftigeren Namen.

[stahli]

Zitat:

Zitat von implementation (Beitrag 1131140)

Soweit es so gewünscht ist, kann man den Wert ja auch der Methode einfach übergeben:

Wenn man Visit den Parameter V zusätzlich mitgibt, kann man Visit natürlich nicht mehr zentral für alle Visitor-Klassen verwenden. Daher würde ich es grundsätzlich wohl bevorzugen den Wert als Eigenschaft VisitorClass.V zu übergeben.

Zitat:

Zitat von implementation (Beitrag 1131143)

Zitat:

Zitat von stahli (Beitrag 1131120)

Ein sinnvollerer Procedurname als "TuWasBesonderes" könnte dann wohl "Do", "DoVisit" oder "Visit" sein. Oder wie macht Ihr das üblicherweise?

Am sinnvollsten ist es natürlich, sie nach dem zu benennen, was sie machen soll ;)
"Visit" nennt man üblicherweise die Methoden des Visitors. Die Methode in der Klasse, die ich hier "TuWasBesonderes" genannt habe, heißt in der Literatur zumeist "Accept".
In der Praxis gibt man ihr aber lieber einen aussagekräftigeren Namen.

Jetzt komme ich wieder durcheinander. Wenn Du z.B. TVisitorAdd, TVisitorDel, TVisitorIrgendwas nutzt, dann würdest Du für jede "Nutzung" eine passende Methode in dem Objekt definieren? Den Vorteil (wenn überhaupt) hätte ich eher darin gesehen, dass man den Objekten nicht dutzende Methoden verpassen muss.

Ich will Dir an der Stelle nochmal für den Beitrag danken!
Auch wenn ich einige Bedenken bezüglich Aufwand+Nutzen habe bin ich doch froh, das Prinzip nun endlich verstanden zu haben. :thumb:

[implementation]

Zitat:

Zitat von stahli

Jetzt komme ich wieder durcheinander. Wenn Du z.B. TVisitorAdd, TVisitorDel, TVisitorIrgendwas nutzt, dann würdest Du für jede "Nutzung" eine passende Methode in dem Objekt definieren?

Natürlich reicht auch eine ;)

Zitat:

Zitat von stahli

Ich will Dir an der Stelle nochmal für den Beitrag danken!
Auch wenn ich einige Bedenken bezüglich Aufwand+Nutzen habe bin ich doch froh, das Prinzip nun endlich verstanden zu haben. :thumb:

Kein Ding ;)

[Uwe Raabe]

Wer des Englischen mächtig ist, kann sich ja weitere Informationen in meiner 4-teiligen Artikelserie zu diesem Thema anlesen.

[implementation]

Zitat:

Zitat von Uwe Raabe (Beitrag 1131155)

Wer des Englischen mächtig ist, kann sich ja weitere Informationen in meiner 4-teiligen Artikelserie zu diesem Thema anlesen.

Grad mal überflogen, sehr ausführlich :thumb:
Und viel ansehnlichere Beispiele als ich.

[mquadrat]

Der Vorteil ist natürlich, dass ich beim Visitor Polymorphie nutzen kann, aber so wirklich gefällt mir das Pattern nicht.

[madas]

Zitat:

Zitat von mquadrat (Beitrag 1131215)

Der Vorteil ist natürlich, dass ich beim Visitor Polymorphie nutzen kann, aber so wirklich gefällt mir das Pattern nicht.

Ich finde es ganz praktisch. Vor Allem, wenn es um das Speichern bzw. Laden von Datenstrukturen in bzw. aus bestimmte(n) Dateiformate(n) geht. Dafür schreibt man einfach einen Load- bzw. Save-Visitor und gut ist. Sollte sich das Dateiformat od. der Dateiaufbau ändern wird einfach ein neuer Visitor geschrieben. So kann man auch eine gewisse Versionierung des Dateiformates/aufbaus beibehalten.

[madas]

Zitat:

Zitat von implementation (Beitrag 1131097)

Hallo liebe Forumsgenossen,

so manch einer von euch ist sicherlich schonmal in folgende Situation geraten:

Ihr habt sehr viele Klassen, die alle eine neue gemeinsame Methode bekommen sollen, die sich aber nicht zentral im Vorfahren einfügen lässt (bspw. weil sich jede Unterklasse anders verhalten soll).
Nun könntet ihr die Methode in jeder dieser Klasse einzeln einführen. Dann hättet ihr die Methoden der jeweiligen Klasse immer schön beieinander.

Delphi-Quellcode:

type
  TClass1 = class
    procedure AndereMethode;
    procedure BlubbNochMehr;
    // ...
    procedure TuWasBesonderes;
  end;
  TClass2 = class
    procedure IchKannWas;
    procedure GanzAnderes;
    // ...
    procedure TuWasBesonderes;
  end;

// TClass1
procedure TClass1.AndereMethode;
begin
  MachWas;
  MachNochMehr;
end;
...
procedure TClass1.TuWasBesonderes;
begin
  Writeln('Ich bin Klasse 1');
end;

// TClass2
procedure TClass2.IchKannWas;
begin
  MachIrgendwas;
  GuckBloed;
end;
...
procedure TClass2.TuWasBesonderes;
begin
  Writeln('Ich bin Klasse 2');
end;

Nun könnt ihr im Nachhinein schön jede Klasse an sich überblicken.

Nun mag manchmal aber etwas anderes viel sinnvoller sein:
Wäre es nicht viel schöner, alle TuWasBesonderes() auf einmal an einer zentralen Stelle im Blick zu haben?

Die Viererbande hat sich dazu ein schönes Pattern ausgedacht: Den Visitor.

Delphi-Quellcode:

// Unit A
type
  IVisitor = interface
    procedure Visit(const x: TClass1); overload;
    procedure Visit(const x: TClass2); overload;
  end;
  TClass1 = class
    // viele Methoden...
    procedure TuWasBesonderes(const v: IVisitor);
  end;
  TClass2 = class
    // viele Methoden...
    procedure TuWasBesonderes(const v: IVisitor);
  end;

procedure TClass1.TuWasBesonderes(const v: IVisitor);
begin
  v.Visit(self);
end;

procedure TClass2.TuWasBesonderes(const v: IVisitor);
begin
  v.Visit(self);
end;

Delphi-Quellcode:

// Unit B
uses UnitA;

type
  TVisitorA = class (TInterfacedObject, IVisitor)
    procedure Visit(const x: TClass1); overload;
    procedure Visit(const x: TClass2); overload;
  end;
  TVisitorB = class (TInterfacedObject, IVisitor)
    procedure Visit(const x: TClass1); overload;
    procedure Visit(const x: TClass2); overload;
  end;

procedure TVisitorA.Visit(const x: TClass1);
begin
  Writeln('Visitor A mit Klasse 1');
end;

procedure TVisitorA.Visit(const x: TClass2);
begin
  Writeln('Visitor A mit Klasse 2');
end;

procedure TVisitorB.Visit(const x: TClass1);
begin
  Writeln('Visitor B mit Klasse 1');
end;

procedure TVisitorB.Visit(const x: TClass2);
begin
  Writeln('Visitor B mit Klasse 2');
end;

Und da können wir auch noch mehr Vorteile sehen:

• Wir können nicht nur einen Visitor schreiben, sondern gleich mehrere! Dadurch hat der Aufrufer von TuWasBesonderes() auch eine bessere Möglichkeit, den Ablauf zu beeinflussen. Neue Visitoren lassen sich schnell dazuergänzen, überlegen Sie mal, wie schnell es nun ginge, noch einen Visitor C hinzuzufügen.
• Es lassen sich auch schnell neue Klassen ergänzen. Angenommen wir führen nun eine neue Klasse 3 ein, müssen wir sie nur IVisitor.Visit() aufrufen lassen, und sie in den Visitoren ergänzen.
• Wir können damit die gesamte TuWasBesonderes()-Funktionalität in eine eigene Unit auslagern.

Mfg und in der Hoffnung, geholfen zu haben,
implementation

Kritik ist erwünscht, also scheut euch nicht ;)

Das Ganze kannste auch noch ein wenig eleganter lösen, da in TuWasBesonderes immer
das Gleiche gemacht wird:

Delphi-Quellcode:

// Unit A
type
   IVisitor = interface
     procedure Visit(const x: TClass1); overload;
     procedure Visit(const x: TClass2); overload;
   end;
   TVisitableBase = class
     procedure AcceptVisitor(const v: IVisitor);
   end;
   TClass1 = class(TVisitableBase)
     // viele Methoden...
   end;
   TClass2 = class(TVisitableBase)
     // viele Methoden...
   end;

procedure TVisitableBase.AcceptVisitor(const v: IVisitor);
begin
   v.Visit(self);
end;

[TiGü]

Wirklich? Ein volles Zitat? :o

[stahli]

Zitat:

Zitat von madas (Beitrag 1131227)

Das Ganze kannste auch noch ein wenig eleganter lösen, da in TuWasBesonderes immer
das Gleiche gemacht wird:

Delphi-Quellcode:

...
   TVisitableBase = class
     procedure AcceptVisitor(const v: IVisitor);
   end;
   TClass1 = class(TVisitableBase)
     // viele Methoden...
   end;
   TClass2 = class(TVisitableBase)
     // viele Methoden...
   end;

Es ging ja auch darum, dass die Klassen keine gemeinsame Basis haben müssen.

[madas]

Zitat:

Zitat von stahli (Beitrag 1131234)

Es ging ja auch darum, dass die Klassen keine gemeinsame Basis haben müssen.

Muss ich wohl überlesen haben. Sorry.
Aber dann macht es für mich keinen Sinn, Klassen ohne gemeinsame Basis mit diesem
Pattern zu versehen.
So bald in mehr als einer Klasse zwei Properties od. Methoden od. od. gleich heißen, sollte man meiner Meinung nach darüber nachdenken, ob sie nicht einen gemeinsamen Vorfahren bekommen sollten.

[Stevie]

In diesem Zusammenhang find ich das Decorator Pattern sehr erwähnenswert. Dieses würde ich in bestimmten Fällen vorziehen. Einen Serializer z.B. würde ich (zumindest in neuen Delphi Versionen) niemals als Visitor sondern als Decorator implementieren.

[implementation]

Zitat:

Zitat von madas (Beitrag 1131227)

Das Ganze kannste auch noch ein wenig eleganter lösen, da in TuWasBesonderes immer
das Gleiche gemacht wird:

Delphi-Quellcode:

// Unit A
type
   IVisitor = interface
     procedure Visit(const x: TClass1); overload;
     procedure Visit(const x: TClass2); overload;
   end;
   TVisitableBase = class
     procedure AcceptVisitor(const v: IVisitor);
   end;
   TClass1 = class(TVisitableBase)
     // viele Methoden...
   end;
   TClass2 = class(TVisitableBase)
     // viele Methoden...
   end;

procedure TVisitableBase.AcceptVisitor(const v: IVisitor);
begin
   v.Visit(self);
end;

Nein, so geht's nicht. Hier würde ja jedes mal v.Visit(TVisitableBase) aufgerufen werden.
Das gibt's aber nicht. Es gibt lediglich Überladungen mit TClass1 und TClass2 und die muss ich auch entsprechend aufrufen ;)

[madas]

Zitat:

Zitat von implementation (Beitrag 1131266)

Nein, so geht's nicht. Hier würde ja jedes mal v.Visit(TVisitableBase) aufgerufen werden.
Das gibt's aber nicht. Es gibt lediglich Überladungen mit TClass1 und TClass2 und die muss ich auch entsprechend aufrufen ;)

Glaube ich nicht Tim, da Self in dem Moment eigentlich den Type der abgeleiteten Klasse haben müsste und nicht nur TVisitableBase.

Grüße.

[madas]

Zitat:

Zitat von Stevie (Beitrag 1131257)

In diesem Zusammenhang find ich das Decorator Pattern sehr erwähnenswert. Dieses würde ich in bestimmten Fällen vorziehen. Einen Serializer z.B. würde ich (zumindest in neuen Delphi Versionen) niemals als Visitor sondern als Decorator implementieren.

Danke für Deinen Hinweis. Werde ich mir bei Gelegenheit einmal anschauen.

Grüße.

[SebE]

Zitat:

Zitat von madas (Beitrag 1131269)

Zitat:

Zitat von implementation (Beitrag 1131266)

Nein, so geht's nicht. Hier würde ja jedes mal v.Visit(TVisitableBase) aufgerufen werden.
Das gibt's aber nicht. Es gibt lediglich Überladungen mit TClass1 und TClass2 und die muss ich auch entsprechend aufrufen ;)

Glaube ich nicht Tim, da Self in dem Moment eigentlich den Type der abgeleiteten Klasse haben müsste und nicht nur TVisitableBase.

Grüße.

Das weiß der Compiler doch nicht!
Overloading kommt doch über die Übersetzungszeit garnicht hinaus.

[stahli]

Ich erkenne auch kein Problem.
Die Klassen TClass1 und TClass2 müssen dem Compiler natürlich bekannt sein.
Und Self ist ja dann vom Typ TClass1 oder TClass2.
M.E. sollte eine solche Vererbung funktionieren.

[madas]

Zitat:

Zitat von stahli (Beitrag 1131275)

Ich erkenne auch kein Problem.
Die Klassen TClass1 und TClass2 müssen dem Compiler natürlich bekannt sein.
Und Self ist ja dann vom Typ TClass1 oder TClass2.
M.E. sollte eine solche Vererbung funktionieren.

implementation hat tatsächlich recht. Zu diesem Zeitpunkt hat Self den Type TVisitableBase. Hatte das anders in Erinnerung. Daher habe ich noch mal in einem alten Projekt nach gekramt und siehe da, dort hatte ich nur eine Methode Visit(element: TVisitableBase). In dieser wurde auf den Type von element getestet und dann mit dem gecasteten Element weiter verfahren.

Frage ist warum ein Test den richtigen Type ermitteln kann, aber Self nicht selbst von diesem Type ist???

Delphi-Quellcode:

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls;

type
  TVisitableBase = class;

  TVisitor = class(TPersistent)
  public
    constructor Create;

    procedure Visit(element: TVisitableBase); virtual;
  end;

  TVisitableBase = class(TPersistent)
  private
    FCaption: String;
  protected
  public
    constructor Create(caption: String);

    procedure AcceptVisitor(visitor: TVisitor); virtual;

    property Caption: String read FCaption write FCaption;
  end;

  TVisitableDerived = class(TVisitableBase)
  private
    FCount: Integer;
  public
    constructor Create(caption: String; Count: Integer);
    destructor Destroy; override;

    property Caption;
    property Count: Integer read FCount write FCount;
  end;

  TVisitorDerived = class(TVisitor)
  public
    constructor Create;

    procedure Visit(element: TVisitableDerived); overload;
  end;

  TForm1 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

{ TVisitableBase }

procedure TVisitableBase.AcceptVisitor(visitor: TVisitor);
begin
  if (Assigned(visitor)) then
    visitor.Visit(Self);
end;

constructor TVisitableBase.Create(caption: String);
begin
  inherited Create;
  FCaption := caption;
end;

{ TVisitor }

constructor TVisitor.Create;
begin
  inherited;
end;

procedure TVisitor.Visit(element: TVisitableBase);
begin
  if (element is TVisitableDerived) then
    ShowMessage('caption: ' + element.Caption + '; count: ' + IntToStr(TVisitableDerived(element).Count))
  else
    raise Exception.Create('Fehler: Base');
end;

{ TVisitableDerived }

constructor TVisitableDerived.Create(caption: String; Count: Integer);
begin
  inherited Create(caption);
  FCount := count;
end;

destructor TVisitableDerived.Destroy;
begin

  inherited;
end;

{ TVisitorDerived }

constructor TVisitorDerived.Create;
begin
  inherited Create;
end;

procedure TVisitorDerived.Visit(element: TVisitableDerived);
begin
  raise Exception.Create('Fehler: Derived');
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  visitor: TVisitorDerived;
  element: TVisitableDerived;
begin
  visitor := TVisitorDerived.Create;
  element := TVisitableDerived.Create('Test', 100);
  try
    element.AcceptVisitor(visitor);
  finally
    element.Free;
    visitor.Free;
  end;
end;

end.

[implementation]

Darf ich mal kurz was in die Runde werfen?

Runtime <> Compiletime ;)

In TVisitableBase.Accept ist der formale Typ von Self: TVisitableBase, also wird die Überladung Visit(TVisitableBase) genommen.
In TVisitableDerived wird diese Methode jetzt nur vererbt, ohne dass sich der formale Typ von Self dort ändert, also ändert sich auch nicht, welche Überladung genommen wird.
Zur Laufzeit steckt in dieser Variable aber dann natürlich ein TVisitableDerived.

Wenn wir Accept in der abgeleiteten Klasse jetzt neu deklarieren, ist der formale Typ von Self dort nun TVisitableDerived, und es wird auch die richtige Überladung genutzt.

[stahli]

Oh ja. Ich hatte übersehen, dass overload schon zur Compilezeit ausgewertet wird. :oops:

Dann dürfte aber der Code

Delphi-Quellcode:

// Unit A
 type
    IVisitor = interface
      procedure Visit(const x: TClass1); overload;
      procedure Visit(const x: TClass2); overload;
    end;
    TVisitableBase = class
      procedure AcceptVisitor(const v: IVisitor);
    end;
    TClass1 = class(TVisitableBase)
      // viele Methoden...
    end;
    TClass2 = class(TVisitableBase)
      // viele Methoden...
    end;
 
procedure TVisitableBase.AcceptVisitor(const v: IVisitor);
 begin
    v.Visit(self);
 end;

nicht kompilieren, da es ja keine überladene procedure Visit für TVisitableBase gibt - oder?

[Uwe Raabe]

Feature Request: man bohre das Syntax-Higlighting soweit auf, daß es nicht-compilierenden Code mit der Fehlerstelle markiert...

[Stevie]

Sieht aus, als ob man an dieser Stelle gut double dispatch gebrauchen könnte.

[implementation]

Zitat:

Zitat von stahli (Beitrag 1131302)

nicht kompilieren, da es ja keine überladene procedure Visit für TVisitableBase gibt - oder?

Genau.