Class Helper als Lösung für zirkuläre Unit-Referenzen

[Furtbichler]

Zitat von Der schöne Günther:

Interfaces muss ich in die gleiche Unit packen.

Nein, natürlich nicht. Aber hier schon (wg. zirkulärer Referenz).
[/QUOTE] Und wenn ich nun schon zwei artfremde Interfaces in eine Datei packe, kann ich auch gleich die paar Zeilen mehr für die Klassen angehen und wieder alles in einen Topf werfen.[/QUOTE]
Ich sagte doch: Eine Datei mit allen Interfaces ist allemal übersichtlicher als eine Datei mit allen Klassen.

Delphi-Quellcode:

Type
  IBesitzer = interface ...
    IHund : Hund;
  end;


  IHund = interface
   Besitzer : IBesitzer;
  end;

Und die Implementierung in separaten Dateien.

[Lemmy]

Zitat von Furtbichler:

Ich sagte doch: Eine Datei mit allen Interfaces ist allemal übersichtlicher als eine Datei mit allen Klassen.
...
Und die Implementierung in separaten Dateien.

genau. Und das Vorgehen bewahrt dann einen auch davor an Stellen "aus Versehen" die Implementierung (=Klasse) zu verwenden, wo das Interface ausreicht.

[jaenicke]

Eine andere Lösung ist eben die von mir angesprochene. Die bevorzuge ich eher. Wir benutzen normalerweise auch eine Datei pro Interface und eine pro Klasse. Mit der Lösung funktioniert das problemlos, egal ob mit Interface oder Klasse:

Delphi-Quellcode:

  TCustomDogOwner = class
  public
    procedure Schimpfen;
  end;

  TDog = class
  private
    FOwner: TCustomDogOwner;
  public
    property Owner: TCustomDogOwner read FOwner write FOwner;
  end;

  TDogOwner = class
  private
    FDog: TDog;
  public
    property Dog: TDog read FDog write FDog;
  end;

[Furtbichler]

Die habe ich auch mal verwendet, aber das ist eben ein Trick, der den Code verunstaltet. TDogOwner führt keine neuen Methoden oder Eigenschaften (mit Ausnahme der Referenz) ein. Ich muss also manchmal einen Typecast verwenden und manchmal nicht:

Delphi-Quellcode:

MyDog.Owner.Schimpfen;
if MyDog <> TDogOwner(MyDog.Owner).Dog Then
  Writeln('The dog was stolen');

Welche Klasse sollte man denn verwenden, wenn man einen Hundebesitzer instantiieren will? Das ist nicht klar, weil zwei Klassen existieren, wo eine reicht.

Dient alles nicht der Übersichtlichkeit.

[Der schöne Günther]

Zitat von jaenicke:

Wir benutzen normalerweise auch eine Datei pro Interface und eine pro Klasse. Mit der Lösung funktioniert das problemlos, egal ob mit Interface oder Klasse

Das ist, zumindest bislang, auch mein Stil

Und ich glaube auch generell in der VCL, denn irgendwie haben 3/4 aller Klassen ein "Custom" im Namen, alle die es nicht haben, sind meist abstrakt

Ich bin in meinen ersten Delphi-Monaten bislang nie in die Lage gekommen, Interfaces anstatt abstrakter Klassen zu nehmen. Irgendeine konkrete Teilimplementierung ließ sich bislang immer in eine Oberklasse herausziehen. Aber wie gesagt, ob das obendrüber jetzt nun ein Interface oder eine Klasse ist kümmert ja niemanden.

Zitat von Furtbichler:

TDogOwner führt keine neuen Methoden oder Eigenschaften (mit Ausnahme der Referenz) ein. Ich muss also manchmal einen Typecast verwenden und manchmal nicht

Moment. Ich dachte, das sei nur ein Tippfehler und soll heißen TCustomDogOwner = class(TDogOwner) ?
Dann markiere ich den TDogOwner noch als abstrakt damit mir keiner einen instanziiert.

Zitat von Furtbichler:

Delphi-Quellcode:

if MyDog <> TDogOwner(MyDog.Owner).Dog Then
  Writeln('The dog was stolen');

[Lemmy]

Zitat von jaenicke:

Eine andere Lösung ist eben die von mir angesprochene. Die bevorzuge ich eher. Wir benutzen normalerweise auch eine Datei pro Interface und eine pro Klasse. Mit der Lösung funktioniert das problemlos, egal ob mit Interface oder Klasse:

Du hast völlig recht und ist sicherlich besser als einen ClassHelper zu verwenden. Ich vermeide so was inzwischen allein für die Auflösung von zirkulären Beziehungen eine weitere Vererbungshierarchie einzuführen.

In einem größeren Projekt in dem ich das Businessmodell erstellt habe, fand ich am Ende im Basisframework (das aus ca. 6 Vererbungsebenen bestand) allein 2 Ebenen die ich nur für die Auflösung der zirkulären Referenzen eingeführt hatte. Am Ende waren die beiden Ebenen aber mit Funktionalität so erweitert worden (durch Kollegen), dass die nicht mehr so einfach zu entfernen waren.

Interfaces bieten hier die Möglichkeit einen deutlich lockeren Verbund zu erstellen. Durch die Maßgabe gegen das Interface zu implementieren und nicht gegen eine Implementierung kann ich die Implementierung auch jederzeit austauschen, z.B. um Tests durchzuführen...

Grüße

[jaenicke]

Zitat von Lemmy:

Interfaces bieten hier die Möglichkeit einen deutlich lockeren Verbund zu erstellen. Durch die Maßgabe gegen das Interface zu implementieren und nicht gegen eine Implementierung kann ich die Implementierung auch jederzeit austauschen, z.B. um Tests durchzuführen...

Klar, die Vorteile von Interfaces gibt es, aber solange man Interfaces nicht in die gleiche Datei packt, hat man das gleiche Problem. Bei Interfaces kommt deshalb das gleiche Schema in Frage.

Ich selbst habe das bisher eigentlich immer ohne Kreuzreferenz lösen können.

Zitat von Der schöne Günther:

Moment. Ich dachte, das sei nur ein Tippfehler und soll heißen TCustomDogOwner = class(TDogOwner) ?

Schau mal in den VCL Quelltexten noch einmal.
Custom ist die Basis für konkrete Ableitungen, die dann nicht mehr das Custom drin haben. Zum Beispiel:

Delphi-Quellcode:

  TCustomEdit = class(TWinControl)
  TCustomMemo = class(TCustomEdit)

  TEdit = class(TCustomEdit)
  TMemo = class(TCustomMemo)

[Furtbichler]

Zitat von jaenicke:

aber solange man Interfaces nicht in die gleiche Datei packt, hat man das gleiche Problem.

Und wenn man sie in eine Datei packt (bzw. nur die voneinander abhängigen Interfaces), dann eben nicht. Es ist nun einmal eine Spracheigenschaft von Delphi, mehrere Klassen in einer Datei halten zu können um damit bestimmte Dinge zu regeln (private vs. strict private und eben Forward-Deklarationen).

Der klassische Ansatz ist die Forward-Deklaration:

Delphi-Quellcode:

Type
  THund = Class;

  THundebesitzer = Class
    Property Hund : THund...
  end;
  
  THund = Class
    property Besitzer : THundebesitzer;
  End;

Und eigentlich ist das sehr schön lesbar, denn sobald man auf eine Forward-Deklaration stößt, weiß man, das hier Kreise im Spiel sind.

Im Übrigen löst die VCL das Problem der zirkulären Referenzen ja nicht, weil sie TCustomXXX und TXXX implementiert, sondern indem sie die Klassen in einer Datei vorhält (soweit ich das überschaue, jedenfalls).

[jaenicke]

Zitat von Furtbichler:

Und eigentlich ist das sehr schön lesbar, denn sobald man auf eine Forward-Deklaration stößt, weiß man, das hier Kreise im Spiel sind.

Lesbar schon, gut testbar weniger.