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

[hzzm]

Ich hab hier schon etliche Beitraege gesucht und gefunden, die sich damit befassen, wie man Zirkulaere Unit-Referenzen verhindert.

Ich befinde mich in einer Situation, in der eine zirkulaere Referenz unvermeidbar ist und kam mit einer leicht anderen Loesung hinterm Ofen hervor.

Vielleicht laufe ich damit spaeter in eine Sackgasse, oder ihr kennt andere Gruende warum ich das so nicht machen sollte.

Die Loesung, die ich am oeftesten sehe, beinhaltet ein Umgehen der Rueck-Referenz mit Events. Aber warum eigentlich Events?
Kann ich nicht genauso gut die Funktionen in einer Proxy-unit anlegen und callen?

Delphi-Quellcode:

// MyMain.pas
uses
  UnitX, MyMainProxy;

type
  TMyMain = class(TForm)
    StatusEdit: TEdit;
    procedure SetGUIStatusOn;
  public
    FormCreate(Sender: TObject)
  end;
[...]

procedure TMyMain.FormCreate(Sender: TObject);
begin
  MMSetGUIValue := SetGUIStatusOn;
end;

procedure TMyMain.SetGUIStatusOn;
begin
  StatusEdit.Text := 'PowerMonger status ON!';
end;

Delphi-Quellcode:

// MyMainProxy.pas
unit MyMainProxy;

interface

var
  MMSetGUIValue: Procedure of Object;

implementation

end.

Delphi-Quellcode:

// UnitX.pas (zirk. Ref. <-> MyMain benoetigt)
uses
  MyMainProxy;
  
procedure UnitX.PerformHCoreOperation;
begin
  MMSetGUIValue;
end;

[Headbucket]

Hallo hzzm,

wenn ich dich richtig verstehe, dann versuchst du eine einfache Callback-Funktionalität zu realisieren, richtig? Du möchtest also in UnitX.pas deine MainForm aktualisieren.
Was an deinem Beispiel ungünstig ist, ist die globale Variable in der Unit MyMainProxy. Diese könnte von jeder Stelle aus dem Programm überschrieben werden und dann wunderst du dich vllt später, weshalb etwas nicht funktioniert.

Eine einfache andere Möglichkeit wäre z.B. folgende:
Du erstellst eine Klasse in UnitX.pas, welche das Feld "FMMSetGUIValue: Procedure of Object;" enthält (public)
In der MyMain.pas erzeugst du diese Klasse und weißt dem Feld "FMMSetGUIValue" die Funktion "SetGUIStatusOn" zu.
Nun kannst du in UnitX.pas an jeder beliebigen Stelle FMMSetGUIValue aufrufen. Vergiss aber nicht vorher mit Assigned zu prüfen, ob dem Feld auch wirklich eine Funktion zugewiesen wurde.

Grüße
Headbucket

[hzzm]

Wie kann ich denn auf Deine oder meine Art Parameter uebergeben?
Wenn ich ein Objekt als "Procedure of Object" initialisiere, funktioniert keine Syntax um einen Parameter mit anzugeben; MMSetGUIValue(Name: String);

Beim Zuweisen im FormCreate geht's auch nicht:

Code:

MMSetGUIValue := SetGUIStatusOn(Name: String);

"')' erwartet, aber ':' gefunden.

[Uwe Raabe]

Zitat von hzzm:

Wie kann ich denn auf Deine oder meine Art Parameter uebergeben?

Delphi-Quellcode:

type
  TMySetGUIValueProc = procedure(const Value: string) of object;
var
  MMSetGUIValue: TMySetGUIValueProc = nil;



procedure UnitX.PerformHCoreOperation;
begin
  MMSetGUIValue('Hallo MainForm!');
end;

Entspricht ungefähr diesem Vorgehen: How to access delphi function at DPR scope

[hzzm]

Danke Euch beiden.
Funktioniert wunderbar, auch in meinem (fraglichen) Original Schnipsel:

Delphi-Quellcode:

unit StatusProxy;

interface

var
  STFBenutzerEinstellen: Procedure(Name: String) of Object;
  STFGUILeeren: Procedure of Object;

implementation

end.

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