AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

Pattern: Visitor

Ein Thema von implementation · begonnen am 18. Okt 2011 · letzter Beitrag vom 19. Okt 2011
Antwort Antwort
Seite 3 von 4     123 4      
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
4.008 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#21

AW: Pattern: Visitor

  Alt 19. Okt 2011, 13:04
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.
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight
  Mit Zitat antworten Zitat
Benutzerbild von implementation
implementation

Registriert seit: 5. Mai 2008
940 Beiträge
 
FreePascal / Lazarus
 
#22

AW: Pattern: Visitor

  Alt 19. Okt 2011, 13:40
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
  Mit Zitat antworten Zitat
madas

Registriert seit: 9. Aug 2007
207 Beiträge
 
#23

AW: Pattern: Visitor

  Alt 19. Okt 2011, 14:02
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.

Geändert von madas (19. Okt 2011 um 14:09 Uhr)
  Mit Zitat antworten Zitat
madas

Registriert seit: 9. Aug 2007
207 Beiträge
 
#24

AW: Pattern: Visitor

  Alt 19. Okt 2011, 14:09
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.
  Mit Zitat antworten Zitat
SebE

Registriert seit: 31. Jul 2004
Ort: Chemnitz
316 Beiträge
 
Delphi 7 Personal
 
#25

AW: Pattern: Visitor

  Alt 19. Okt 2011, 14:15
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.
Sebastian
  Mit Zitat antworten Zitat
Benutzerbild von stahli
stahli

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
4.336 Beiträge
 
Delphi 11 Alexandria
 
#26

AW: Pattern: Visitor

  Alt 19. Okt 2011, 14:22
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.
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)
  Mit Zitat antworten Zitat
madas

Registriert seit: 9. Aug 2007
207 Beiträge
 
#27

AW: Pattern: Visitor

  Alt 19. Okt 2011, 14:42
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.
  Mit Zitat antworten Zitat
Benutzerbild von implementation
implementation

Registriert seit: 5. Mai 2008
940 Beiträge
 
FreePascal / Lazarus
 
#28

AW: Pattern: Visitor

  Alt 19. Okt 2011, 15:05
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.
  Mit Zitat antworten Zitat
Benutzerbild von stahli
stahli

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
4.336 Beiträge
 
Delphi 11 Alexandria
 
#29

AW: Pattern: Visitor

  Alt 19. Okt 2011, 15:14
Oh ja. Ich hatte übersehen, dass overload schon zur Compilezeit ausgewertet wird.

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?
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)
  Mit Zitat antworten Zitat
Benutzerbild von Uwe Raabe
Uwe Raabe
Online

Registriert seit: 20. Jan 2006
Ort: Lübbecke
11.009 Beiträge
 
Delphi 12 Athens
 
#30

AW: Pattern: Visitor

  Alt 19. Okt 2011, 15:17
Feature Request: man bohre das Syntax-Higlighting soweit auf, daß es nicht-compilierenden Code mit der Fehlerstelle markiert...
Uwe Raabe
Certified Delphi Master Developer
Embarcadero MVP
Blog: The Art of Delphi Programming
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 3 von 4     123 4      


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 21:05 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz