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

[bernau]

Zitat von namenlozer:

ich packe klassen, die sich gegenseitig benötigen, einfach in dieselbe unit. So schlimm ist das gar nicht.

dito.

[Der schöne Günther]

Zitat von Furtbichler:

Innerhalb von THund kannst Du ja gar nicht auf den Hundebesitzer zugreifen. Somit ist diese Umschiffung (eine Lösung ist das ja nicht) des Henne-Ei-Problems mittels Classhelper vielleicht ein Notbehelf, aber imho ein ziemlich einengender.

Zitat von silver-moon-2000:

Ich kann also innerhalb von THund auf den Besitzer entweder über das property direkt zugreifen oder über das ungecastete Objekt, wobei ich dann jedes Mal casten muss?

Das habe ich in dem Kurzbeispiel ausgelassen: Den gleichen Class Helper hätte ich jetzt in den implementation -Teil von Hund.pas gesetzt. Somit muss ich auch intern in THund den Zeiger in den Nebel nicht casten. Außerdem könnte ich diesen "internen" Helper ja noch um eine zweite Property (bzw. Getter-Methode) erweitern, die ein anderes Verhalten aufweist als die "normale" für "von außen". Auch wenn das jetzt nicht mein Fall wäre...

Zitat von jaenicke:

Denn die Frage ist doch was man von dem Objekt Hund im Objekt Besitzer machen will. Meistens kann man das auch über Events oder ähnliches lösen.

Guter Einwand! Das wird bestimmt zu oft übersehen (auch von mir).

Zitat von Furtbichler:

Wieso verwendest Du nicht einfach Interfaces? Wenn man das konsequent durchzieht und keine kranken Sperenzien anstellt, gibt es auch keine Probleme.

Vielleicht ist es für mich noch zu früh am Morgen - Aber wo hilft mir das? Angenommen beide Klassen müssen sich gegenseitig kennen. Sie sind so unterschiedlich, ich finde keine sinnvolle Abstraktion die auf beide zutrifft. IHund muss nun eine Property vom Typ IHundesitzer nach außen führen und umgekehrt. Oder war das anders gedacht? Interface nur für einen von beiden (wie auch hier nur Helper-Klasse für einen)?

Außerdem hätte ich spontan Angst vor der automatischen Referenzzählung durch Interfaces - Mit der habe ich noch keine Erfahrung: Zwei Instanzen referenzieren sich nun gegenseitig, außerhalb davon hat die Welt allerdings bereits mit ihnen abgeschlossen. Nun trudeln die beiden auf ewig Hand in Hand durch meinen Speicher. Kennt Delphi etwas wie "Weak References"?

Zitat von NamenLozer:

Ich packe Klassen, die sich gegenseitig benötigen, einfach in dieselbe Unit. So schlimm ist das gar nicht. Lange Units sind halt auch irgendwie der Pascal-Way... guckt euch doch nur mal die VCL an.

Wenn ich kleine Kinder in Angst und Schrecken versetzen will, tue ich das mit der System.pas: Knappe 40.000 Zeilen kann doch keiner mehr ernst meinen. Da braucht man sich dann auch nicht mehr zu wundern, wenn man für ein "Hallo Welt" schon 20 Megabyte braucht.

[Daniel]

Zitat von Der schöne Günther:

Da braucht man sich dann auch nicht mehr zu wundern, wenn man für ein "Hallo Welt" schon 20 Megabyte braucht.

Doch, eigentlich schon - das mit den Klassen hat der Linker ganz gut drauf - wenn Du 10 Klassen in einer Unit hast und nur eine verwendest, landet auch nur die in der EXE. Das allein ist kein Argument gegen mehrere Klassen in einer Unit.

[Der schöne Günther]

Stimmt! Da hätte ich auch selber drauf kommen können, da der Linker mir immer gerne Klassen rausoptimiert hatte, die im Quelltext nicht direkt erwähnt, sondern nur indirekt über die RTTI gesucht wurden

Nur in den alten Pascal-Units (wie System.pas) ist ja an sich mindestens 90% eben nicht objektorientiert, sondern nur alleine rumbaumelnde Funktionen. Ob der Linker das auch kann?

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