Globale Variablen - warum in der DP so verpönt?

[new4toms]

Liebe DPler,

ich habe diesen Thread angezettelt, da ich ein recht umfangreiches Projekt betreue - mit globalen Variablen (und sogar GOTOs).

Die (noch nicht nachgezählt, dürften aber so rund 400 sein) sind jedoch in(zwischen/seit langem) in einer eigenen Unit "ausgelagert" und tragen Namen, die nicht gerade so aussehen:

i:=Integer;

sondern eher so:

iGthisM_id_42.

i steht für Integer, G für Global, thisM_id_42 für den Datensatz.

Was mich nach wie vor - an den "Global-Gegnern" irritiert:

Wie macht Ihr denn die Einstellung für ein Programm, das mehr als 150 Optionen - verteilt auf ca. 25 Forms anbietet? In jedem Form eine Einstellungsoption? In jedem Objekt ein eigenes "ReadFromIniFile"?

M.M.n. lassen sich größere Anwendungen nur mit globalen Variablen beherrschen. Bestes Beispiel: Die Registry von Windows selbst!

1:0 für die globalen Variablen, oder?

mfg

[alcaeus]

Zitat:

Zitat von new4toms

Wie macht Ihr denn die Einstellung für ein Programm, das mehr als 150 Optionen - verteilt auf ca. 25 Forms anbietet? In jedem Form eine Einstellungsoption? In jedem Objekt ein eigenes "ReadFromIniFile"?

Also ich fuer meinen Teil habe ein Optionsobjekt, in dem alle Optionen gesammelt sind. Dieses Optionsobjekt wird aber als globale Variable zur Verfuegung gestellt, also (IMHO) die ideale Kombination aus globalen Variablen und OOP ;)

Zitat:

Zitat von new4toms

M.M.n. lassen sich größere Anwendungen nur mit globalen Variablen beherrschen. Bestes Beispiel: Die Registry von Windows selbst!

Naja, egal wie man Optionen speichert, und egal wie man sie dann im Programm zur Verfuegung stellt, das sind 2 Paar Schuhe. Im Gegenteil: die Speicherung sollte unabhaengig von der Verwendung im Programm sein. Deshalb verwende ich dafuer auch eine zweite Klasse. So kann ich ohne Probleme von meinem eigenen Format mit cfg-Dateien auf ini-Files oder die Registry umstellen.

Zitat:

Zitat von new4toms

1:0 für die globalen Variablen, oder?

Fuer dich. Andere sehen den Sieg fuer OOP-Konzepte, ich sehe es immer noch als 0:0. Einen eindeutigen Sieger kann und wird es nicht geben. Jeder verwendet das, mit dem er fuer sich besser klarkommt. Fuer dich moegen das Globals sein, fuer andere sind es Objekte. Das muss am Ende jeder fuer sich entscheiden.

Greetz
alcaeus

[Sanchez]

Zitat:

Zitat von new4toms

Wie macht Ihr denn die Einstellung für ein Programm, das mehr als 150 Optionen - verteilt auf ca. 25 Forms anbietet? In jedem Form eine Einstellungsoption? In jedem Objekt ein eigenes "ReadFromIniFile"?

Das klingt für mich nach einem zentralen Einstellungs-Objekt, am besten ein Singleton. Jede Option wird eine Property und es gibt eine Methode zum Lesen und eine zum Schreiben.

Zitat:

Zitat von new4toms

1:0 für die globalen Variablen, oder?

Nö. :mrgreen:

grüße, daniel

[Muetze1]

Moin!

Zitat:

Zitat von MrSpock

2. OOP wird in der Regel in sicherheitskritischer Software nicht eingesetzt. Ich arbeite in Standardisierungsgremien, in denen wir uns darüber Gedanken machen. Viele der Großen wie Boeing, Lockheed Martin, EADS sind da eher zögerlich.

Hier sehe ich die Gründe eher darin, das die Systeme in denen diese sicherheitskritische Software umgesetzt wird, kein OOP können bzw. OOP nicht echtzeittauglich ist und daher nicht eingesetzt werden kann. Ich denke da z.B. Matlab/Simulink, wo man nicht alle Elemente des Matlab's einfach so für Echtzeit nutzen kann, da diese nicht dafür tauglich sind.

Auch bei Steuerung wie SPS, wird meistens kein OOP eingesetzt, da es meist über das Ziel hinaus schiesst. Ein komplettes OOP in eine solche SPS zu knallen - da kommt man auf keinen grünen Zweig mehr, da ist man mit einem kleinen nicht-OOP Code besser dran bzw. auch schneller und überschaubarer.

MfG
Muetze1

[runger]

Hallo Sanchez,

das haut dir mein Chef um die Ohren!
Ca 500 Variablen die global sein müssen, weil Sie von 50 Forms benutzt werden!
Dann singleton, property, procedure...
Mein Chef sagt:
Junge du spinnst. Machs einfach, machs mit globalen Variablen.
kostet nur ein zehntel!

Rainer

[Sanchez]

Hallo runger,

Der Unterschied zwischen dem Anlegen einer globalen Variable und einer Property im Singleton ist IMHO minimal. Das ist mir der Vorteil, die Methoden bei den Daten zu haben schon Wert.

grüße, daniel

[runger]

Hallo Sanchez,

bitte gib mir mal ein minimales Codebeispiel damit wir von der gleichen Sache reden.
Für ein Property brauch ich:
-property selber
-Function zum setzen
-Variable selbst

zum Zugriff Zuweisung

für eine globale Variable (alle in der gleichen Unit. Nicht verteilt das wäre katastrophal):
-globale Variable

zum Zugriff Zuweisung

Für die Function brauche ich mindestens 5 Zeilen.

Und was bring das Ganze? Garnichts! Mein Code ist so übersichtlich wie deiner.

Wohlgemerkt: wenn jemand globale Variablen streut bin ich voll deiner Meinung, ansonsten nicht!

Rainer

[Sanchez]

Wenn jede Property mit Funktionen ausgestattet wird, dann wirds natürlich länger. Sofern das nicht nötig ist, lasse ich die Property auf die Variable direkt zugreifen. Wenns nur um Einstellungen geht, dann kann ich auf Setter-Methoden verzichten.

Ein konkretes Beispiel ist eine Klasse, die mir beim Programmstart lokalisierte Strings lädt. Im Programm greifen mehrere Threads beliebig auf diese Strings zu. Da die Properties alle nur Lesbar sind, benötige ich keine Setter- bzw. Getter-Methoden. Andernfalls könnte in denen die Thread-Synchronisation ablaufen.

Delphi-Quellcode:

type
  TMenuMessages = class(TObject)
  private
    FString1: string;
    FString2: string;
    ...
    {1 Lädt die Übersetzungen }
    procedure LoadMessages;
  protected
    constructor Create;
    constructor CreateInstance;
    class function AccessInstance(Request: Integer): TMenuMessages;
  public
    destructor Destroy; override;
    class function Instance: TMenuMessages;
    class procedure ReleaseInstance;
  published
    property String1 : string read FString1;
    property String2 : string read FString2;
    ...
  end;

LoadMessages wird im Konstruktor aufgerufen. Den Klassenrumpf vom Singleton generiert mir dabei der Modelmaker. In Wirklichkeit ist der einzige Vorteil aber, dass ich die Laden-Methode bei den Daten habe.

Eine neue Variable würde in dem Fall eine neue Property und eine Zeile in LoadMessages bedeuten.
Theoretisch könnte ich LoadMessages auch noch automatisieren indem ich von TPersistent ableite und über alle Published-Properties iteriere. Allerdings setze ich in der den Default-Wert und müsste mir dafür noch was überlegen.

Für bessere Lösungen bin ich aber immer offen.

[runger]

Hallo Sanchez,

eins hast du geschafft, du hast mich neugierig gemacht.
Ich werde zumindest über die Art wie ich das Ganze realisiert habe
nachdenken!

Rainer

[Chewie]

Zitat:

Zitat von runger

Für die Function brauche ich mindestens 5 Zeilen.

Und was bring das Ganze? Garnichts!

Nein. Ein einfaches Beispiel ist eine multi-threaded Anwendung (mistiges Denglisch, aber mir fiel grad kein deutsches Wort dafür ein :shock: ), die auf globale Variablen schreibend zugreift. Wenn du das mit einfachen globalen Variablen machst - viel Spaß beim Synchronisieren!
Auch müsstest du bei jedem Schreibzugriff prüfen, ob der Wert erlaubt ist. Da ist eine set-Funktion (oder eben eine Methode) wesentlich einfacher und auch weniger zu schreiben.