Globale Variablen

[Pseudemys Nelsoni]

Hoi,

ich benutze ziemlich oft globale variablen, ich höre aber immer wieder das das scheisse ist.
Nun mal meine Frage: Wie soll ich denn einen zustand aus 2 prozeduren heraus sonst ändern? soll ich die variablen in einer datei ablagen?(ist wohl noch blöder)...wie gesagt ich möchte mit 2 prozeduren einen zustand(bolesche variable) prüfen...aber wie mach ich sowas ohne globale variablen ?

[Daniel B]

Indem Du an etwas OOP denkst und Dir ne neue Klasse machst... Zum Bleistift...

[Daniel B]

Da gibts auch noch ein Thread zu dem Thema:
http://www.delphipraxis.net/internal...hlight=globals

[Pseudemys Nelsoni]

was meinst du mit neuer klasse?
In dem thread seh ich leider auch keine alternative zu globalen variablen :(

[Luckie]

Globale Variablen sind nicht generell schlecht. Man sollte nur wissen, was man tut.

[Pseudemys Nelsoni]

hoi luckie, jo, genau so denke ich (eigentlich) auch.
Aber ich kriege das halt oft zu hören, da ich manchmal viele globale habe.
zum beispiel sowas(macht keinen sinn aber so als beispiel eben):

Delphi-Quellcode:

VAR irgendwas: Boolean;

Delphi-Quellcode:

procedure 1;
  begin
    irgendwas := false;
  end;

Delphi-Quellcode:

procedure 2;
  begin
    irgendwas := true;
  end;

also mit 2 proceduren, eine bestimmte variable ändern, für mich gibts da eigentlich nur dateien wo man die variable reinpackt, die registry, oder eben die globale variable....letztere ist ja wohl die einfachste...oder geht es auch noch anders?

[sakura]

Wie wäre es denn mit der Nutzung von Klassenfeldern - die von mir bevorzugte Methode und bei uns im Hause auch erzwungene Methode ;-) Kündigungen können ja soooo einfach ausgestellt werden :mrgreen:

...:cat:...

[Christian Seehase]

Moin Silent,

bei den von Dir genannten Beispiel könntest Du ja mal prüfen, ob es nicht sinnvoll wäre die beiden Prozeduren als Methoden zu des Formulares zu deklarieren, und die Variable als Eigenschaft/Feld im Formularobjekt, oder ob es eventuell sinnvoll wäre diese drei Teile in einer eigenen Klasse zusammenzufassen, die dann wiederum als Typ einer Eigenschaft eines anderen Objektes dient.

Ausserdem kann man noch zwischen unit- und projektglobal unterscheiden.
Wird die Variable erst unter implementation deklariert so ist sie für andere Units nicht sichtbar, und somit würde sich die Gefahr verringern die Variable unbeabsichtigt zu verändern.
Am gefährlichsten ist eben die Deklaration im interface Abschnitt.

[Pseudemys Nelsoni]

sakura: wie verwende ich die ? :pale:

christian: dein erklärung ist sicher für gute programmierer spitze erklärt, ich versteh sie allerdings nicht so, da ich nicht weiss wie ich die beiden prozeduren als methoden des formulars benutzen könnte, und mit klassen hab ich noch nicht gearbeitet. :\

gibt es ein beispiel?

[SirThornberry]

Delphi-Quellcode:

TForm1 = class(TForm)
private
 irgendwas: Boolean;
 procedure do1;
 procedure do2;

[...]
var
 form1: TForm1;
[...]

procedure TForm1.do1;
begin
 irgendwas := False;
end;

procedure TForm1.do2;
begin
 irgendwas := False;
end;

oder

Delphi-Quellcode:

TForm1 = class(TForm)
public
 irgendwas: Boolean;

[...]
var form1: TForm1;
[...]

procedure do1;
begin
 form1.irgendwas := False;
end; 

procedure do2;
begin
 form1.irgendwas := False;
end;

[Christian Seehase]

Moin Silent,

ich meine nahezu das Gleiche wie sakura.

Delphi-Quellcode:

type
  TForm1 = class(TForm)
    // Was halt so auf dem Formular ist
    // ergänzt um Deine Prozeduren
    procedure MyProc1;
    procedure MyProc2;
  private
    // Klassenfeld (wie sakura schon sagte)
    Firgendwas: boolean;
  public
    // Als Eigenschaft veröffentlicht, damit ggf. von Aussen zugegriffen werden kann
    // ansonsten kann man das auch weglassen
    property irgendwas : boolean read FfVariable;
  end;

//...

implementation

procedure TForm1.MyProc1;
begin
  irgendwas := false;
end;

procedure TForm1.MyProc2;
begin
  irgendwas := true;
end;

Oder als eigenes Objekt:

Delphi-Quellcode:

type
  TMyClass = class(TObject)
  private
    Firgendwas : boolean;
  public
    procedure MyProc1;
    procedure MyProc2;
    // Wiederum bei Bedarf
    property irgendwas : boolean read Firgendwas;
  end;

implementation

procedure TMyClass.MyProc1;
begin
  irgendwas := false;
end;

procedure TMyClass.MyProc2;
begin
  irgendwas := true;
end;

Eingebunden z.B. in das Formular

Delphi-Quellcode:

type
  TForm1 = class(TForm)
    //...
    procedure FormCreate(sender: TObject);
    procedure FormDestroy(sender: TObject);
  private
    FMyObject : TMyClass;
  public
    property MyObject : TMyClass read FMyObject;
  end;

implementation

// In OnCreate des Formulares erstellen
procedure TForm1.FormCreate(sender: TObject);
begin
  FMyObject := TMyClass.Create;
end;

// und im OnDestroy wieder freigeben
procedure TForm1.FormDestroy(sender: TObject);
begin
  FreeAndNil(FMyObject);
end;

War das so als Beispiel verständlich?

[Pseudemys Nelsoni]

SirThornBerrie,Christian: das hilft mir ziemlich weiter, danke für die mühe 8)

Zitat:

War das so als Beispiel verständlich?

auf jeden fall :wink:

[Matze]

Ich hätte mal eine Frage dazu:

Wieso sind globale Variablen denn schlecht? :gruebel:

Mit Luckies Beitrag:

Zitat:

Zitat von Luckie

Globale Variablen sind nicht generell schlecht. Man sollte nur wissen, was man tut.

fange ich nicht so viel an.

[Daniel B]

Weil man solche Variablen von überall und aus jeder Prozedur verändern kann. Irgendwann wenn man zuviele hat, verliert man einfach die Übersicht, wann welche Variable welchen Zustand hat... Solange man es im Griff hat, kann man sie ja ruhig benutzen, wenn Du aber 50 Stück hast und 3000 Prozeduren und von überall und zzu jeder Zeit kannst Du die Globals verändern, ich glaube das Du da nicht mehr weisst, oder durchdenken kannst, wann welche Variable wie aussieht.

[Alexander]

..und vor allem, wenn du dir den Quellcode ein Jahr später ankuckst :mrgreen:

[Matze]

Achso, vielen Dank!

Ich dachte schon, das Programm wird dadurch langsamer. Ich hatte maximal 40 proceduren bis jetzt. :mrgreen: