Variablen/Objecte Applicationsweit verfügbar machen

[Hobbycoder]

Hi,

wenn ich z.B. eine ObjectList in der Main erzeuge, auf diese aber auch von weiteren Formen zugreifen will (z.B. zum Füllen einer Combobox), dann muss ich die immer an/durch alles Units durchreichen.
Zur Zeit mache ich das so:
UnitMain:

Delphi-Quellcode:

private
  TestListe: TTestListe;

Procedure Create;
  TestListe:=TTestListe.create;

procedure Destroy;
  TestListe.Free;

Unit A:

Delphi-Quellcode:

public
  TestListe: TTestListe;

und irgendwo im Code setzte ich dann UnitA.Testliste=Main.Testliste.

Sieht jetzt beschissen aus, aber ihr wisst was ich meine. Wenn ich jetzt in UnitA irgendwas mit der TestListe mache, ist das halt die aus der MainUnit.

Wie kann ich das besser machen, so dass die TestListe auf der Mainunit in allen anderen Units zur Verfügung steht, ohne dass ich sie hier so durchreiche und ohne dass ich in UnitA die UnitMain in die Uses aufnehmen müsste (will ich nämlich nicht).

[DeddyH]

Ich weiß ja nicht, ob ich Dein Anliegen richtig verstanden habe, aber Du könntest diese Liste ja in einer eigenen Unit erzeugen und wieder freigeben. Allerdings müsstest Du dann wiederum diese Unit statt der MainUnit einbinden.

[hoika]

Hallo,
mit so einer GlobalsUnit muss aber nichts "durchgereicht werden",
sondern immer nur diese eine Unit.

[Hobbycoder]

Etwas so:

Delphi-Quellcode:

unit Unit1;

interface

uses System.Classes, System.Generics.Collections;

type
  TTestObject=class
  private
    Fblabla: string;
    procedure Setblabla(const Value: string);
  published
    property blabla: string read Fblabla write Setblabla;
  end;

  TTestList=class(TObjectList<TTestObject>);

var
  TestListe: TTestList;

implementation

{ TTestObject }

procedure TTestObject.Setblabla(const Value: string);
begin
  Fblabla := Value;
end;

initialization
  TestListe:=TTestList.Create(True);

finalization
  TestListe.Free;

end.

Und das reicht?

[Hobbycoder]

Hab's grad mal ausprobiert. So wie oben hat es soweit gut funktioniert.

Rein theoretisch könnte ich dann diese Unit auch in einen thread aufnehmen und auch von dort auf das object zugreifen. Müsste dieser Zugriff ebenfalls über synchronize abgesichert werden? oder reichte es, dass der Zugriff mittels Getter/Setter in der Unit geregelt ist?

[a.def]

Zitat:

Variablen/Objecte Applicationsweit verfügbar machen

Ich benutze dafür immer Record-Typen wo alle Variablen, Objekte usw drin sind.
Keine Setter, keine Getter, nix. Einfach nur ein Record.

[Hobbycoder]

Records würden natürlich auch gehen. Obiger code ist ja nur ein Beispiel.
Das Object im aktuellen Projekt existiert bereits und enthält noch einige Listen, etc. Von daher werde ich das so lassen.

Zitat:

Zitat von a.def (Beitrag 1368933)

Keine Setter, keine Getter, nix. Einfach nur ein Record.

Das beantwortet aber meine Frage nicht.

[Aviator]

Entweder Getter und Setter (mit TCriticalSection) oder den TMultiReadExclusiveWriteSynchronizer (nie selbst benutzt) oder beim Schreiben mit Synchronize absichern. Das sollte es eigentlich gewesen sein. Mir gefällt da die CriticalSection Variante am Besten. Zumindest ist sie relativ einfach umzusetzen.

Es gibt da soweit ich weiß auch noch TMonitor. Habe ich aber auch noch nie benutzt und kann daher auch nicht sagen wie gut/schlecht das funktioniert.

[a.def]

Bei sehr vielen Zugriffen in sehr kurzer Zeit ist TMonitor deutlich langsamer als CriticalSections.
Musste ich damals leider herausfinden, nachdem ich alles auf TMonitor umgebaut hatte.

[himitsu]

Durchreichen hat aber den Vorteil, dass alle Programmmodule unabhängig, wiederverwenbar und einzeln Testbar/austauschbar sind,
wenn die keine Verbindung zur TForm1 haben.

Klar, manche kommen jetzt vielleicht auch auf die Idee überall Unit1 einzubinden und dann über Form1.TestListe drauf zuzugreifen (die Variable oder ein Property in Public),
anstatt diese Variable in eine gemeinsame Unit auszulagern und sie überall einzubinden.


Mal ein Beispiel für
* Klassen-Methoden/Property statt globalen Variablen
* Klassen-Konstructororen statt Initialization

Die Delphi-Programme würden schneller starten und, bräuchten weniger RAM und hätten kleinere EXEn, wenn die RTL/VCL/FMX nicht ständig alles in Initialiazation machen würden, was dann eh fast niemand braucht, aber durch das Initialization ständig mit eingebunden wird.

Kann man auch in einen Record oder die TTestList-Klasse einfügen.

Delphi-Quellcode:

type
  TTestObject = class
  private
    Fblabla: string;
    procedure Setblabla(const Value: string);
  published
    property blabla: string read Fblabla write Setblabla;

  private class var
    FTestListe: TObjectList<TTestObject>;
  private
    class function GetTestListe: TObjectList<TTestObject>; static;
  public
    //class constructor Create;  // statt des initialization, aber wird nur aufgerufen, wenn die Klasse TTestObject auch im Programm verwendet wird
    //property TestListe: TObjectList<TTestObject> read FTestListe;
    class property TestListe: TObjectList<TTestObject> read GetTestListe;  // erst erzeugen, wenn auch wirklich gebraucht wird (alternativ eben schon im class constructor)
    class destructor Destroy;  // statt des finalization, aber wird nur aufgerufen, wenn die Klasse TTestObject auch im Programm verwendet wurde
  end;

implementation

{ TTestObject }

procedure TTestObject.Setblabla(const Value: string);
begin
  Fblabla := Value;
end;

class function TTestObject.GetTestListe: TObjectList<TTestObject>;
begin
  if not Assigned(FTestListe) then
    FTestListe := TTestList.Create(True);
  Result := FTestListe;
end;

class destructor TTestObject.Destroy;
begin
  FreeAndNil(TestListe);  // bei globalen Variablen besser immer FreeAndNil, statt Free ... dann knallt es schöner, wenn jemand nach Freigabe nochmal grauf zugreift
end;

Und zum Thema Synchronisation, falls aus mehreren Threads zugegriffen wird, wurde schon viel geschrieben,
aber ich erwähne auch mal die TThreadList.