Visitor Pattern

[hansmaad]

Guten morgen,

ich versuche gerade meinen ersten Delphi Visitor zu schreiben und bin natürlich auf die wohl bekannten zirkulären Probleme gestoßen. Ich habe mit der Suche einige Themen gefunden, wo darüber gesprochen wird, eine Lösung aber nur erwähnt wird.
Da ich ein recht umfangreiches Composite habe, möchte ich auf keinen Fall alles in eine Datei packen. Ich wär daher daran interessiert ob es überhaupt eine Lösung dazu gibt und wie diese aussieht.

Delphi-Quellcode:

unit Base;
interface
type
    Visitor = class;
    Base = class
    public
      procedure Accept(v : Visitor);virtual;abstract;
    end;

    A = class(Base)
    public
      procedure Accept(v : Visitor);override;
    end;

    B = class(Base)
    public
      procedure Accept(v : Visitor);override;
    end;

    Visitor = class
    public
        procedure Visit(a : A); overload;
        procedure Visit(b : B); overload;
    end;

implementation

{ Visitor }
procedure Visitor.Visit(a: A);
begin
    WriteLn('A');
end;

procedure Visitor.Visit(b: B);
begin
    WriteLn('B');
end;

{ B }
procedure B.Accept(v: Visitor);
begin
    v.Visit(Self);
end;

{ A }
procedure A.Accept(v: Visitor);
begin
    v.Visit(Self);
end;

end.

Delphi-Quellcode:

var
    list : TList<Base>;
    v : Visitor;
    x : Base;
begin
    list := TList<Base>.Create;
    v := Visitor.Create;
    list.Add(A.Create);
    list.Add(B.Create);

    for x in list do
        x.Accept(v);

    list.Free;
    v.Free;
    ReadLn;
end.

A soll nun in UnitA, B in UnitB und Visitor in UnitVisitor.
Wie löst ihr sowas? Setzt ihr vielleicht auch irgendwelche sinnvollen Alternativen zu Visitor ein? Ich seh bei mir irgendwie nur die Möglichkeit alles in A und B zu implementieren und sie zu Gottklassen mutieren zu lassen.

GRüße
hansmaad

[mkinzler]

Funktioniert nur wenn alle Klassen in der selben Unit deklariert werden.
Aber warum benötigst du eigentlich die Typen A,B?

[himitsu]

Delphi-Quellcode:

Visitor = class
public
  procedure Visit(a : A); overload;
  procedure Visit(b : B); overload;
end;

Wieso 2 verschiedene Methoden, wo sie doch genau das Selbe machen?

Delphi-Quellcode:

Visitor = class
public
  procedure Visit(b: Base); 
end;

procedure Visitor.Visit(b: Base);
begin
  WriteLn(b.ClassName);
end;

Und schon muß Visitor und Base deine A und B nicht kennen und schon kannst du Visitor und Base in eine Unit packen und A, sowie B lassen sich in anderen Units unterbringen.

"x" kann als Basisklasse ja die beiden abgeleiteten Klassen/Objekte entgegennehmen.

Es muß sich also in der Hauptunit alles nur mit der Basisklasse erledigen lassen und das Klassenspezifische muß halt überschrieben und von den Subklassen erledigt werden.




Aber ansonsten hast du (wie Markus schon sagte) keine Chance und mußt alles in der selben Unit verpacken.

[hansmaad]

Zitat von himitsu:

Wieso 2 verschiedene Methoden, wo sie doch genau das Selbe machen?

Sie machen doch nicht das selbe?! Die eine schreibt 'A', die andere schreibt 'B'.
Das ist doch der Sinn des Vistor Patterns. Für jedes ConcreteElement gibt es unterschiedliches Verhalten, dass aber nicht in der Element Klasse, sondern in einem (konkreten) Visitor implementiert ist.


Meine jetzige Alternativlösung ist folgende:

Delphi-Quellcode:

unit UBase;
uses UWriter;
type
    Base = class
    public
      function MakeWriter(): Writer; virtual; abstract;
    end;

Delphi-Quellcode:

unit UWriter;
interface
type
    Writer = class
    public
        procedure Write();virtual;abstract;
    end;

Delphi-Quellcode:

unit UA;

interface
uses
    UBase,UWriter;

type
    A = class(Base)
    public
        function MakeWriter() : Writer ;override;
    end;

implementation
uses
    UAWriter;

{ AA }

function A.MakeWriter: Writer;
begin
    Result := AWriter.Create(Self);
end;

Delphi-Quellcode:

unit UAWriter;
interface
uses
    UWriter,
    UA;

type
    AWriter = class(Writer)
    public
        constructor Create(x : A);overload;
        procedure Write();override;
    end;

implementation

{ AWriter }

procedure AWriter.Write;
begin
    WriteLn('A');
end;

end.

Das hat gegenüber Visitor den Nachteil, dass ich bei neuer Funktionalität in jeder Elementklasse(A, B...) eine neue Schnittstelle hinzufügen muss, statt nur einen neuen Visitor abzuleiten. Der Nutzen hängt natürlich immer vom Verhältnis Elemente:Vistors ab und was sich wie häufig ändert. Wenn häufig Elemente hinzukommen, kann Visitor auch recht lästig sein.

Mir scheint Visitor in Delphi allerdings sehr aufwändig, wenn nicht unmöglich zu implementieren zu sein.

Zum konkreten Fall:
Base, A, B .. sind Elemente eines Composite (Teile einer Anlage). Stellt euch das WriteLn('A') als Schreiben eines seitenlangen Berichts vor. Von solchen Sachen gibt es ein paar...Dinge, die man möglichst von A, B usw. trennen möchte.

[mkinzler]

Zitat:

Das ist doch der Sinn des Vistor Patterns. Für jedes ConcreteElement gibt es unterschiedliches Verhalten, dass aber nicht in der Element Klasse, sondern in einem (konkreten) Visitor implementiert ist.

da sie sich aber im Interface nicht unterscheiden, kannst du der Visitorklasse auch Elemente vom (abstrakten) übergelagerten Typ (Base) übergeben.

[hansmaad]

okok... das Beispiel war wohl zu minimiert.

Delphi-Quellcode:

unit Base;
interface
type
    Visitor = class;
    Base = class
    public
      procedure Accept(v : Visitor);virtual;abstract;
    end;

    A = class(Base)
    public
      procedure Accept(v : Visitor);override;
      function AZeugs() : String;
    end;

    B = class(Base)
    public
      procedure Accept(v : Visitor);override;
      function BZeugs() : String;
    end;

    Visitor = class
    public
        procedure Visit(a : A); overload;
        procedure Visit(b : B); overload;
    end;

implementation

{ Visitor }
procedure Visitor.Visit(a: A);
begin
    WriteLn(a.AZeugs());
end;

procedure Visitor.Visit(b: B);
begin
    WriteLn(b.BZeugs());
end;

//...

end.