Die alte Leier: Zirkulaere Referenzen, aber warum nicht so: ...?

[freimatz]

Dem habe ich nichts hinzuzufügen außer bei einem Punkt. Folgendes reizt mich zum Widerspruch:

Zitat von hzzm:

Ich befinde mich in einer Situation, in der eine zirkulaere Referenz unvermeidbar ist ...

Ich behaupte eine zirkulaere Referenz kann man immer vermeiden.

[Delphi-Laie]

Zitat von freimatz:

Dem habe ich nichts hinzuzufügen außer bei einem Punkt. Folgendes reizt mich zum Widerspruch:

Zitat von hzzm:

Ich befinde mich in einer Situation, in der eine zirkulaere Referenz unvermeidbar ist ...

Ich behaupte eine zirkulaere Referenz kann man immer vermeiden.

Das ist eine Fragestellung, die m.E. die theoretische Informatik berührt.

Wüßte ich auch gern.

Was sagen die studierten Informatiker dieses Forums dazu?

[jaenicke]

Man kann eine formale zirkuläre Referenz immer durch andere Konstrukte ersetzen. Der Zugriff in beide Richtungen bleibt aber trotzdem erhalten. Sei es über Callbacks oder durch Entkoppelung mit Interfaces.
(Schaust du in den Callstack siehst du in beiden Richtungen die Zugriffe.)

Interfaces haben den Vorteil, dass man auf der Konsumentenseite, sprich bei der Verwendung des Interfaces, keinerlei Bezug auf die Klasse hat, die dieses Interface implementiert. Trotzdem kann man alle im Interface veröffentlichten Methoden frei verwenden.

Bei Callbacks oder Events wie hier im Thread diskutiert trennt man die einzelnen Teile der Implementierung weniger und ist nicht so flexibel. Für einfache Fälle reicht das aber vollkommen aus.

[Fritzew]

Zitat:

Interfaces haben den Vorteil, dass man auf der Konsumentenseite, sprich bei der Verwendung des Interfaces, keinerlei Bezug auf die Klasse hat, die dieses Interface implementiert. Trotzdem kann man alle im Interface veröffentlichten Methoden frei verwenden.

Das unterschreibe ich sofort. Ganz abgesehen davon hat man damit effektiv die Möglichkeit einzelne Code Abschnitte sauber testen zu können. Ich habe die letzten 18 Monate damit zugebracht ein riesiges Projekt (3 Millionen Zeilen) zu refactorieren. Der Business Code, nicht die GUI! ist jetzt zu ca 98 % unter Test. Ich liebe Interfaces!!! Erzählt das aber nicht meiner Frau

[himitsu]

Statt Interfaces gibt es auch die Möglichkeiten des OOP.
Also Vererbung und einen Vorfahren mit abstrakten Methoden und Feldern/Variablen verwenden.

Vom Prinzip her also wie mit Interfaces und Rückreferenzierung der Instanzen.

Durch Rückreferenzierung von Interfaces/Objekte/Callbacks in die andere Unit oder in eine gemeinsam genutzt Unit kann man solche verketteten Unitreferenzen auflösen.
Zirkuläre Unitreferenzen sind aber auch nichts anderes, als eine Rückreferenzierung auf aktive Inhalte der unter Implementation eingebunden Unit, welche sich ebenfalls zur Laufzeit erst auflöst.

Statt statischer Verbindungen kann man auch erstmal komplett lose entwickeln, ohne dass sich Beide kennen, und die gegenseitigen Referenzierungen erst zur Laufzeit aufbauen, über systemglobale Objekte (FindWindow, NamedPipe, NamedMMF, GetProcAdress usw.)
Aber prizipiell ist es auch wieder das Selbe, nur dass hier die Rückreferenzierung nicht innerhalb der Delphi-Units, sondern über die gemeinsam genutzte Dinge aus System-DLLs erledigt wird.

[EWeiss]

Zitat:

@Fritzew Das unterschreibe ich sofort.

Ich auch

Nachdem du mir dabei geholfen hast mit den Interfaces zurecht zu kommen arbeite ich auch sehr gerne damit.
Da ist man wirklich sehr flexibel.

gruss

[hzzm]

Zitat von EWeiss:

Nachdem du mir dabei geholfen hast mit den Interfaces zurecht zu kommen

Gibt es zu Deinem Lern-Prozess Threads hier?
Ich moechte mir diese Technik auch aneignen, finde aber leider keine interface Beispiele, die genau fuer diesen Zweck angelegt sind.
Ich brauch das einfach mal schwarz auf weiss, minimal und vollstaendig.