Globale Variablen richtig nutzen

[OlliWW]

Hallo Zusammen,

Ich habe ein großes Projekt und an verschiedenen Stellen im Programm muss ich auf "allgemeine Einstellungen" zu greifen - solche Dinge wie: Datenbankeinstellungen, oder andere Dinge die ich mir "merken" möchte.

Dies sind lediglich einfache Datentypen wie Integer oder Strings.

Wie implementiere ich dies in Delphi am Besten?

Nutze ich einfach eine Unit, in der ich öffentliche Variablen (ob jetzt direkt oder per Getter Setter sei mal dahin gestellt) deklariere und nutze. Oder sollte ich dies über ein Singleton-Pattern machen, oder liefert Delphi vielleicht schon eine Art "Grundfunktion" mit, die ein solches Management übernehmen kann?

Manche Variablen werden während der Laufzeit ermittelt und können sich auch ändern.

[stahli]

Das ist reine Geschmacksache.

Es sollten möglichst Verwechslungen ausgeschlossen werden.

Wenn Du

Delphi-Quellcode:

I: Integer = 0;

irgendwo global ablegst besteht die Gefahr, dass Du irgendwo mal versehentlich auf ein lokales I zugreifen willst, aber die lokale Deklaration vergisst und somit die globale Variable benutzt.

In dem Fall wäre vielleicht global_I schon sinnvoller.

Du kannst auch (mit etwas neueren Delphiversionen) eine Klassenvariable nutzen:

Delphi-Quellcode:

TGobals = class
  class var
    I: Integer;
end;

und so benutzen:

Delphi-Quellcode:

X := TGlobals.I;

So hat man etwas mehr Ordnung in den Units.


Ein Singleton ist sinnvoll, wenn man Objekte bei Bedarf einmalig erstellen lässt und dann künftig immer diese Instanz verwendet. Das hilft Dir bei einfachen Typen nicht.

[a.def]

Zitat:

Zitat von stahli (Beitrag 1358880)

Du kannst auch (mit etwas neueren Delphiversionen) eine Klassenvariable nutzen:

Delphi-Quellcode:

TGobals = class
  class var
    I: Integer;
end;

Mit älteren Delphi-Versionen dementsprechend

Delphi-Quellcode:

type
 TGlobals = packed record

 I: Integer;
end;

var
 aGlobals: TGlobals;

// Benutzung
X := aGlobals.I;

[nahpets]

Hab' mir für diese "Problem" mal 'ne Komponente gebaut, die so diverses Konfigurationsgedöns selbständig ermittelt bzw. speichert bzw. die vom Anwender gemachten Angaben per Setter annimmt und speichert und beim Neustart des Programmes restauriert.

Auf alles kann per Property zugegriffen werden.

Jedes Programm bekommt auf's MainForm die Komponente gepappt und schon ist das Grundgerüst fertig.

Ein paar Sachen kann man dann im Objektinspektor anpassen, soweit erforderlich.

[Zacherl]

Zitat:

Zitat von OlliWW (Beitrag 1358877)

Nutze ich einfach eine Unit, in der ich öffentliche Variablen (ob jetzt direkt oder per Getter Setter sei mal dahin gestellt) deklariere und nutze. Oder sollte ich dies über ein Singleton-Pattern machen, oder liefert Delphi vielleicht schon eine Art "Grundfunktion" mit, die ein solches Management übernehmen kann?

Ich persönlich verwende für solche Dinge immer Singletons. Grade für Einstellungen bietet sich das an, da man dann alles schön übersichtlich in einer Klasse zusammenfassen (und den Klassennamen als Namespace missge-brauchen) kann. Bei diesem konkreten Fall erstelle ich mir meistens einen Record der Form:

Delphi-Quellcode:

type
  TSettings = record
  strict private
    class var Ini: TIniFile;
  strict private
    // Setter und Getter
  public
    class constructor Create; // Ini erzeugen und Einstellungen laden
    class destructor Destroy; // Einstellungen speichern und Ini freigeben
  public
    property Setting1;
    property Setting2;
    // ..
  end;

Falls du mit

Delphi-Quellcode:

class constructor

bzw.

Delphi-Quellcode:

class destructor

nicht vertraut bist: Diese Methoden werden automatisch einmalig aufgerufen (sofern die Klasse irgendwo im Code referenziert wird) und zwar erfolgt

Delphi-Quellcode:

Create

beim Programmstart und

Delphi-Quellcode:

Destroy

kurz vor Beendigung. So ähnlich wie die

Delphi-Quellcode:

initialization

und

Delphi-Quellcode:

finalization

Abschnitte in Units.

[Blup]

Den Anwendungskern solltest du immer so realisieren, dass nicht direkt auf globale Variablen zugegriffen wird. Nur so kann dieser unabhängig von der Anwendung getestet werden. Dafür bietet sich z.B. eine Schnittstelle an, die nur die Aufgabe hat solche Umgebungsvariablen bereitzustellen.
Beispiel:

Delphi-Quellcode:

interface
  IAnwendungsfall1Config = Interface(IInterface)
    [GUID]
    function GetSetting1: Integer;
    procedure SetSetting1(AValue: Integer);
    function GetSetting2: string;
    property Setting1: Integer read GetSetting1 write SetSetting1;
    property Setting2: string read GetSetting2;
  end;

  TAnwendungsfall1Config = class(IAnwendungsfallConfig)
    constructor Create(var ASetting1: Integer; const ASetting2: string);
  private
    FSetting1: PInteger; 
    FSetting2: string;
  public
    function GetSetting1: Integer;
    procedure SetSetting1(AValue: Integer);
    function GetSetting2: string;
  end;   

  TAnwendungsFall1 = class()
    constructor Create(const AConfig: IAnwendungsfallConfig; const AFileApi: IFileApi; const ADbFramwork: IDbFramwork);
  private
    FConfig: IAnwendungsfallConfig;
    FFileApi: IFileApi;
    FDbFramwork: IDbFramwork;
  public
    procedure TuWas;
  end;

implementation

constructor TAnwendungsfall1Config.Create(var ASetting1: Integer; const ASetting2: string);
begin
  FSetting1 := @ASetting1;
  FSetting2 := ASetting2;
end;

function TAnwendungsfall1Config.GetSetting1: Integer;
begin
  Result := FSetting1^;
end;

procedure TAnwendungsfall1Config.SetSetting1(AValue: Integer);
begin
  FSetting1^ := AValue;
end;

function TAnwendungsfall1Config.GetSetting2: string;
begin
  Result := FSetting2;
end;

constructor TAnwendungsFall1.Create(const AConfig: IAnwendungsfallConfig; const AFileApi: IFileApi; const ADbFramwork: IDbFramwork);
begin
  inherited Create;
  FConfig     := AConfig;
  FFileApi    := AFileApi; 
  FDbFramwork := ADbFramwork; 
end;

procedure TAnwendungsFall1.TuWas;
begin
  FConfig.Setting1 := FFileApi.TuWas(FConfig.Setting1);
  FDbFramwork.TuWas(FConfig.Setting2);
end;

Erzeugen des Anwendungsfalls in der Anwendung:

Delphi-Quellcode:

   Config := TAnwendungsfall1Config.Create(GlobaleVariable1, GlobaleVariable2);
   AnwendungsFall1 := TAnwendungsFall1.Create(Config, GlobalFileApi, GlobalDbFramwork);

Im Testprojekt würde man beim Erzeugen für jeden Testfall eigene Variablen nutzen und die API simulieren.

[mm1256]

Zitat:

Zitat von OlliWW (Beitrag 1358877)

Hallo Zusammen,

Ich habe ein großes Projekt und an verschiedenen Stellen im Programm muss ich auf "allgemeine Einstellungen" zu greifen - solche Dinge wie: Datenbankeinstellungen.....

Die Stichworte sind doch "großes Projekt" und "Datenbankanwendung" und darum ist die Frage - zumindest für mich - vom TE eigentlich schon selber beantwortet: Die Einstellungen gehören sich in eine Datenbank, und dann ist das Ganze auch relativ einfach und schnell netzwerkfähig gemacht, was ich aus den bisherigen Vorschlägen nicht zwingend ableiten konnte.

[OlliWW]

Zitat:

Zitat von mm1256 (Beitrag 1358917)

Die Einstellungen gehören sich in eine Datenbank

Naja mir geht es um kleine Einstellungen wie: Einstellungen FÜR die Datenbank :coder:

[p80286]

Zitat:

Zitat von OlliWW (Beitrag 1358919)

Zitat:

Zitat von mm1256 (Beitrag 1358917)

Die Einstellungen gehören sich in eine Datenbank

Naja mir geht es um kleine Einstellungen wie: Einstellungen FÜR die Datenbank :coder:

Was verstehst Du darunter?

Meiner Meinung nach ist das überhaupt nicht global, da z.B. der Oberfäche es vollkommen egal (sein muß) welche Datenbank wie angesprochen wird.

Gruß
K-H

[Uwe Raabe]

Zitat:

Zitat von p80286 (Beitrag 1359029)

Meiner Meinung nach ist das überhaupt nicht global, da z.B. der Oberfäche es vollkommen egal (sein muß) welche Datenbank wie angesprochen wird.

Na ja, irgendwo muss man der Anwendung ja auch sagen, welche Datenbank sie benutzen soll bzw. wie diese zu erreichen ist. Je nach Zugriffskomponente kann das ein Connectionstring oder ein Server-Name oder sonstwas sein. Ich nehme mal an, daß niemand hier die Datenbank in der Anwendung fest verdrahten will, oder?