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

[Lemmy]

Zitat von jaenicke:

// EDIT:
Interfaces lösen das Problem auch nicht, wenn man tatsächlich eine echte Referenz in beide Richtungen will. Man könnte allerdings die Referenz in einem abgeleiteten Interface unterbringen und nur das Basisinterface zurück referenzieren. Das geht bei Klassen aber auch.

natürlich lösen die Interfaces das Problem. Zumindest wenn man Interfaces wie Interfaces verwendet und nicht wie KLassen

Grüße

[jaenicke]

Zitat von Lemmy:

natürlich lösen die Interfaces das Problem. Zumindest wenn man Interfaces wie Interfaces verwendet und nicht wie KLassen

Sofern du zwei Interfaces hast und die Referenz jeweils auf das andere drin hast, geht das auch nicht. Wenn du ein Basisinterface auf einer der beiden Seiten referenzierst, geht das, aber das geht auch bei Klassen.

Und wenn du ein zusätzliches Interface benutzt, musst du erst dieses zusätzliche Interface nehmen, ggf. mit as drauf casten z.B., das ist auch nicht so schön. Aber es kommt halt drauf an was man genau braucht.

Wenn man die benötigten Funktionen der Besitzerklasse in eine Klasse TCustomBesitzer packt und die Klasse Hund erst in TBesitzer aus einer anderen Unit referenziert, funktioniert es jedenfalls auch.

Die beste Lösung ist aber Kreuzreferenzen zu vermeiden und nicht diese durch Interfaces oder ähnliches zu forcieren, wobei man bei Interfaces dann auch noch aufpassen muss, dass man keine Kreise einbaut, so dass die Objekte nie freigegeben werden.
Dass das Vermeiden nicht immer geht, sieht man ja an den weak references im ARM Compiler für iOS, die genau so etwas dort erlauben.

[Furtbichler]

Interfaces kann man in eine Unit schmeißen, Klassen sollte man -der besseren Übersicht halber- aufteilen. Wenn man das so macht, lösen Interfaces diese Probleme der zirkulären Referenz.

Klar, alles in eine Datei schmeißen geht auch, aber ich hatte da mal dann ca. 10.000 Zeilen in einer Datei und das ist irgendwie uncool.

Dann lieber 500 Zeilen Interfacegedöns in einer Datei und 50 Klassen in 50 separaten Dateien.

Wer das alles partout ausschließen will, bricht sich eben einen ab (z.B. mit anonymen Verweisen, irgendwelchen Drittklassen, die die Beziehung verwalten usw. usw.)

Ich denk dabei immer an KISS. Und zwar so S wie möglich, also KIASAPDABWGU ("keep it as simple as possible, dumb ass, but without getting unübersichtlich"). Oder so ähnlich jedenfalls.

Und wichtig ist: Die Prämisse (KISS+Zusätze) ist am Wichtigsten. Wer meint, eine Datei reicht und ist KISS. Super. Wenn die Kollegen einverstanden sind => Cool. Genauso verhält es sich mit allen angebotenen Lösungen.

[Bjoerk]

Die ClassHelper Lösung finde ich ziemlich suboptimal. Man schau sich nur einmal diese Zeile an:
Writeln(Dog.Master.Dog.Master.Dog.Master.Dog.Name); // "Bobby" Da fängt ja der Hund an zu jaulen, wenn er das lesen könnte.

[Der schöne Günther]

Ja aber genau das ist doch die Intention. Zwei nicht verwandte Instanzen halten beide gegenseitig eine Referenz auf eine artfremde Instanz.

Ob man das jetzt schön findet, was man syntaktisch damit machen kann wenn der Verweis public ist ist doch eine andere Geschichte.

[Der schöne Günther]

Ich habe aus Versehen einen neuen Beitrag verfasst und kann ihn nicht löschen. Sorry

Zitat von Furtbichler:

Interfaces kann man in eine Unit schmeißen, Klassen sollte man -der besseren Übersicht halber- aufteilen.

Ich komme wirklich noch nicht hinterher
Interfaces muss ich in die gleiche Unit packen. 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.

Alternativ (ähnlich den Helpern) für eine der beiden ein Interface. Wenn man sich die Abbildung im Anhang anschaut: So?

[Bjoerk]

Ich verstehe deinen Wunsch, eine allgemeine Lösung zu finden.

Solche generelle Lösungen haben aber auch einen Nachteil, weil sie eigentlich nirgends richtig passen (Kontext).

Hier halt einfach: Das Herrchen hat einen Hund. Damit weiß das Herrchen immer Bescheid. Wenn der Hund was übers Herrchen wissen muß, dann halt per Events.

[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;