globale Variablen?

[olfrygt]

Hallo,

Ich hab gerade angefangen an einem kleinen Rechenprogramm zu basteln.
Es werden nach und nach mehrere Daten vom Nutzer abgefragt. Auf mehreren Seiten.

Mein 1. Problem:

Ich bin nur in der Lage ein einziges Formular zu erstellen und es mit allen Komponenten, die ich irgendwann mal brauche vollzupacken und dann mit der Visible-Eigenschaft zu arbeiten. Das ist, um genau zu sein, abartig unübersichtlich.

Also dachte ich mir, dass ich mehrere Formulare erstelle. Da aber jedes Formular über seine eigene Unit verfügt muss ich die Variablen, die bei der Nutzerabfrage entstehen, für alle Units und somit Formulare verfügbar machen.

Also hab ich nach dem Begriff "globale Variablen" gesucht. Alles was ich gefunden habe, war immer wieder der Hinweis, man solle erst gar keine globalen Variablen verwenden. Warum das so ist, und wie man das Problem anders lösen könnte hab ich nicht verstanden. Zumal ich noch nicht einmal weiß, wie ich das mache, was ich eigentlich nicht machen soll (globale Variablen deklarieren). ^^

Muss ich jetzt die Variable unter dem Abschnitt "Public" deklarieren oder weiter unten, wo schon "Var" steht?
Und muss ich unter "Uses" dann noch den anderen Units sagen, aus welchen anderen Units sie überall globale Variablen beziehen sollen?

MfG

[patti]

Erstelle eine Variable unter "Public" (z.B. in Form1). In der anderen Form (z.B. Form2) kannst du dann mit

Delphi-Quellcode:

Form1.VariablenName := Wert;

darauf zugreifen. Wenn du kompilieren willst, sollte eine Abfrage kommen, ob du die Form-Unit in die Uses-Liste übernehmen willst. Mit Ja bestätigen und neu starten. Fertig!

Patti

[olfrygt]

Dankeschön! :spin2:

*ausprobier*

[Viktorii]

Zitat:

Zitat von patti

Erstelle eine Variable unter "Public" (z.B. in Form1). In der anderen Form (z.B. Form2) kannst du dann mit

Delphi-Quellcode:

Form1.VariablenName := Wert;

darauf zugreifen.
Patti

Ich dachte immer, dass genau das (nicht über Properties sondern direkt auf (public-) Varialben zugreifen) schlechter Programmierstil wäre. Oder habe ich da was falsch verstanden?

[DeddyH]

Zitat:

Zitat von Viktorii

Ich dachte immer, dass genau das (nicht über Properties sondern direkt auf (public-) Varialben zugreifen) schlechter Programmierstil wäre. Oder habe ich da was falsch verstanden?

Du kannst natürlich auch eine Property mit einer Getter- und einer Settermethode schreiben.

[Viktorii]

Zitat:

Zitat von DeddyH

Zitat:

Zitat von Viktorii

Ich dachte immer, dass genau das (nicht über Properties sondern direkt auf (public-) Varialben zugreifen) schlechter Programmierstil wäre. Oder habe ich da was falsch verstanden?

Du kannst natürlich auch eine Property mit einer Getter- und einer Settermethode schreiben.

Ja genau, so dachte ich mir das... Ich dachte immer, wenn man das nicht so macht, also direkt setzt, wäre das pfui....

[DeddyH]

Direkt pfui würde ich nicht unbedingt sagen, auf jeden Fall besser als globale Variablen ;)

[Aurelius]

Was hat dass den eigentlich für Besondere Nachteile (public)? Habe noch nix gefunden was für mich persönlich dagegen sprechen sollte die zu nutzen...

[RavenIV]

Zitat:

Zitat von xX0815Xx

Was hat dass den eigentlich für Besondere Nachteile (public)? Habe noch nix gefunden was für mich persönlich dagegen sprechen sollte die zu nutzen...

Nehmen wir als Beispiel das Gaspedal am Auto.

Direkt über Public-Member:
Du steckst während dem Fahren den Arm aus dem Fenster und betätigst die Steuerklappe am Vergaser/Einspritzer.
Klappe drücken -> schneller fahren, Klappe loslassen -> langsamer fahren.

Nun per Setter-Methode:
Du definierst ein Gaspedal, das man bequem aus dem Innenraum des Autos drücken kann.
Nun kannst Du auch noch einige Sachen überprüfen, bevor die Steuerklappe geöffnet wird.
z.B. ist ein Gang eingelegt?
drehen die Räder schon durch?
ist überhaupt der Motor eingeschaltet?
usw.
Erst wenn alle Überprüfungen erfolgreich gewesen sind, wird die Klappe geöffnet und das Auto fährt.

[Aurelius]

Ich könnte doch aber auch mit weiteren public-Variablen prüfen ob die anderen Bedingungen erfüllt sind und dann die Variable ändern, oder?

[RavenIV]

Zitat:

Zitat von xX0815Xx

Ich könnte doch aber auch mit weiteren public-Variablen prüfen ob die anderen Bedingungen erfüllt sind und dann die Variable ändern, oder?

Nein.

Wenn Du machst:

Delphi-Quellcode:

Form1: TForm...
...
public
  fAbfrageStarten: Boolen;
...
...

Dann in Form2:

Delphi-Quellcode:

Form1.fAbfrageStarten := True;

dann ist AbfrageStarten bereits geändert.

Du könntest natürlich in Form2 machen:

Delphi-Quellcode:

...
if Form1.VerbindungGeoeffnet and Form1.WerteAbgefragt and Form1.DarfGestartetWerden then
begin
  Form1.fAbfrageStarten := True;
end
else
begin
  Form1.fAbfrageStarten := False;
end;

Das müsstest Du dann aber immer machen, wenn Du Form1.AbfrageStarten ändern möchtest.
Also kannst Du es auch gleich im Setter für AbfrageStarten in Form1 erledigen:

Delphi-Quellcode:

Form1: TForm...
...
private
  fAbfrageStarten: Boolean;
  procedure SetAbfrageStarten(...);
...
published
...
  property AbfrageStarten: Boolean write SetAbfrageStarten;
...
end;
...
...

procedure Form1.SetAbfrageStarten(...);
begin
  if ... and ... and ... then
  begin
    ...
    fAbfrageStarten := True;
  end
  else
  begin
    ...
    fAbfrageStarten := False;
  end;
end;

[Aurelius]

So meinte ich das ja (das untere)

[Corpsman]

Das problem an der "unteren" variante ist,

Wenn du deine Unit Veröffentlichst und ein anderer nutzt die Variablen, blickt der niemals das er diese Kointrollen selbst machen mus.

Mittels Get und Set Methoden Sorgst du Unter Garantie dafür das diese Prüfungen gemacht werden.

Zusätzlich hast du ja noch die Möglichkeit bei Properties nur Lesen, oder nur schreiben zu zu lassen.

Also auf das Beispiel mit dem Auto bezogen, kannst du die Gesamtgeschwindigkeit nur Lesen, nicht aber schreiben.

Machst du das mittels einer Public Variable hast du die Möglichkeit des Schreibschutzes nicht.

[DeddyH]

Zitat:

Zitat von xX0815Xx

So meinte ich das ja (das untere)

Da ist es aber doch einfacher und wartbarer, die Überprüfung gleich im Setter vorzunehmen.

Delphi-Quellcode:

TBlubb = class
...
private
  FWert: TWert;
  function GetWert: TWert;
  procedure SetWert(value: TWert);
...
public
  property Wert: TWert read GetWert write SetWert;
...
end;

...

function TBlubb.GetWert: TWert;
begin
  Result := FWert;
end;

procedure TBlubb.SetWert(value: TWert);
begin
  if value <> Quatsch then
    FWert := value;
end;

So ist gewährleistet, dass Du immer plausible Werte verwendest.

[Aurelius]

Aha jetzt habe ich es auch verstanden. Scheint wirklich komfortabler zu sein...

[RavenIV]

Habt Ihr eigentlich meinen Beitrag #11 gesehen?
Der Beitrag mir dem vielen Quellcode...

[DeddyH]

Zitat:

Zitat von RavenIV

Habt Ihr eigentlich meinen Beitrag #11 gesehen?
Der Beitrag mir dem vielen Quellcode...

Jepp, allerdings bevor Du ihn editiert hast ;)

[RavenIV]

Zitat:

Zitat von DeddyH

Jepp, allerdings bevor Du ihn editiert hast ;)

Ich bin da dummerweise auf den Absenden-Button gekommen, bevor ich fertig war. :oops: :roll:

[Khabarakh]

Man sollte noch erwähnen, dass dann konsequenterweise jeglicher "FormX."-Code ebenfalls "pfui" ist ;) .

[RavenIV]

Zitat:

Zitat von Khabarakh

Man sollte noch erwähnen, dass dann konsequenterweise jeglicher "FormX."-Code ebenfalls "pfui" ist ;) .

Häähh?
Ich kann Dir nicht folgen. :? :?:

[Aurelius]

Wenn er damit mein

Delphi-Quellcode:

if Form2.Checkbox1.checked then ...

fände ich das etwas übertrieben^^

[Khabarakh]

Zitat:

Zitat von xX0815Xx

Wenn er damit mein

Delphi-Quellcode:

if Form2.Checkbox1.checked then ...

fände ich das etwas übertrieben^^

Meine ich. Wenn man auf der einen Seite Anfängern von globalen Variablen abrät, gleichzeitig aber die automatisch angelegten Variablen wie "Form1" benutzt, dann grenzt das für mich an Scheinheiligkeit.

[Hansa]

Wird Form1.XXX von anderer Form/Unit aufgerufen, dann deutet dies auf schlechten Stil hin. Nicht mehr und nicht weniger. Die Units aind dann womöglich zu schlecht durchdacht. Globale Variablen werden dadurch schlecht, dass man sie während der Programmlaufzeit verändert, mehrfach neu deklariert eventuell sogar innerhalb einer Prozedur usw. Sind sie nur einmal vorhanden und werden sie nur gelesen, so dass man sie nicht laufend neu lesen muss, dann ist das soweit in Ordnung.

[mkinzler]

Zitat:

Wird Form1.XXX von anderer Form/Unit aufgerufen, dann deutet dies auf schlechten Stil hin.

Noch schlimmer ist es aber, wenn innerhalb einer klasse auf diese "Standard"-Instanz zugegriffen wird.

[Hansa]

Was ist eine Standard-Instanz ? :shock: Solche Fragen über global usw. sind ja durchaus berechtigt. Das Thema hat sich durch OOP völlig gewandelt. Früher hatte man entweder innerhalb einer Prozedur eine Variable oder eben "global". Jetzt gibt es auch globale, die zur Verfügung stehen, sofern die betreffende Unit nur in USES drinsteht, also wie vorher auch. Zusätzlich gibt es aber jetzt Form-Globale, die für die Form gelten und die kann man mit Konstrukten wie Form1.XXX := 123 komplett aushebeln. Hinzu kommt dann noch sowas wie private, protected usw. Dann gibts Variable mit gleichen Namen, die sich je nachdem nicht mal ins Gehege kommen ! Trivial kann man das IMHO nicht mehr nennen.

[mkinzler]

Damit meine ich das Formx, welches vom Formulardesigner automatisch angelegt wird. Wie oft sieht man imn Methoden den Zugriff auf diese Instant anstatt auf die aktuelle (Self).

[Khabarakh]

Zitat:

Zitat von Hansa

Sind sie nur einmal vorhanden und werden sie nur gelesen, so dass man sie nicht laufend neu lesen muss, dann ist das soweit in Ordnung.

Aber genau das ist eben nicht die mehrheitlich vertretene Meinung hier im Forum, wie sich am ersten Posting erkennen lässt:

Zitat:

Alles was ich gefunden habe, war immer wieder der Hinweis, man solle erst gar keine globalen Variablen verwenden.

Und trotz dieser Absage wird weiterhin fröhlich "Form1" getippt, darauf wollte ich hinweisen.
Was nicht heißt, dass ich selbst dir zustimme ;) . Globale Variablen lassen sich _immer_ ohne wirklichen Mehraufwand durch eine objektorientiertere Form ersetzen[*]. Dass sie bei Forms in jedem Fall auf schlechtes Design hinweisen, hast du ja schon erwähnt.
[*] Um wieviel aussagekräftiger und sicherer ist (um bei deinem Beispiel zu bleiben) z.B. eine öffentliche, read-only Klasseneigenschaft als eine globale Variable mit dem darübergesetzten Kommentar "bitte nur lesen, NICHT SCHREIBEN!"? Und Schmankerl wie Lazy Loading gibt's kostenlos dazu.

[Hansa]

Bin mal ein Programm durchgegangen. Es gibt tatsächlich eine Form, die im Stile von FormX.XXX auf Variablen einer anderen zugreift. Wie gesagt : ist schlechter Stil. Aber warum nehme ich das trotzdem in kauf ? Die eine Form hat ca. 10.000 Zeilen. Die zweite dient zum Suchen und braucht sowieso extra Form. Das ist wirklich ein Sonderfall. Die Suchform ist zu groß, um das mit Panelen usw. realisieren zu können. Jetzt muss ich den von der SuchForm gefundenen Datensatz an die Quasi-Hauptform (zumindest in diesem Programmteil) weiterreichen. Nur wie ? Das Ergebnis wird eben einfach weitergereicht. Diese Suchform ist allerdings auch abgeleitet und wird nicht nur einmal verwendet. Somit kann ich sie nicht einfach in die Form, die nur spezielle Sachen braucht integrieren.

wg. roter Kasten : nur-Lese-Eigenschaften als properties einzubauen ist am sichersten. Aber warum ? Nur weil ein Fehler direkt auftaucht. Das ist jetzt echt Zufall, aber ich habe fast den ganzen Tag damit zugebracht, um festzustellen, dass es sich nicht lohnt eine Programm-global gesetzte Property einzubauen. Zum Selbstzweck darf sowas nicht werden.