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

[new4toms]

Die einschlägigen Beiträge habe ich schon gelesen!!!

Globale Variablen machen m.M.n. *nur* dann Ärger, wenn man sie zur "Zwischenspeicherung" von irgendwelchen Informationen benutzt und man seinen *eigenen* Sourcecode dann nicht mehr erkennt.

Bislang hatte ich noch nie Probleme, meinen eigenen Sourcecode wiederzuerkennen.

Womit haben denn die "Globalen-Variablen-Feinde" Probleme?

Mal wirklich ganz naiv gefragt?

Echt neugierig,
new4toms

[dizzy]

Aus meiner Sicht sprechen 2 Dinge gegen globale Variablen:

1) Sie sind im Konzept der OOP nicht existent, und wäre dort (wenn in Reinform praktiziert) auch schlicht unbrauchbar.

2) Sie müllen einem das Projekt voll, und zwar mit ihrem Namen. Wenn ich in Unit1 eine glob. Variable "x" habe, und Unit1 in die uses-Liste von Unit2 aufnehme, so ist "x" dort ebenso gültig. Die Folge ist, dass man z.B. in einer Funktion lokal "x" deklariert, und so lange man sich in dieser Funktion befindet, wird das lokale "x" genommen. Verwende ich das "x" aber an anderer Stelle und halte es aus Versehen für das eben genannte lokale "x", so wird mir der Compiler keinen Error ausspucken, sondern munter mit dem globalen "x" aus Unit1 kompilieren, und somit einen Fehler in der Logik herbeiführen, der dann u.U. nur schwer nachvollziehbar ist. Diese Problematik steigt und fällt natürlich mit der Komplexität eines Projektes, aber allein die Tatsache dass es eine selbst gebaute Fehlerquelle sein kann, disqualifiziert die globalen Variablen im Sinne einer sauberen Programmierung (imho).

Ich muss jedoch zugeben, dass ich bei quick'n'dirty Mini-Mal-Eben-Programmen auch hier und da was global deklariere. Vornehmlich dann, wenn ich nur eine Unit brauche - z.B. um schnell was zu testen. Ansonsten vermeide ich sie wo es geht.

Gruss,
Fabian

[Hansa]

Zitat:

Zitat von new4toms

...Bislang hatte ich noch nie Probleme, meinen eigenen Sourcecode wiederzuerkennen.

Womit haben denn die "Globalen-Variablen-Feinde" Probleme?

Da du ja angeblich bereits alles darüber gelesen hast, müßte dir einiges klar sein, warum das keiner machen sollte. Einzeln zähle ich das deshalb jetzt nicht neu auf. Mehrere Gegenfragen : womit hast denn du Probleme, wenn du glaubst sie benutzen zu müssen ? Wie groß ist denn dein Programm überhaupt ? Meinst du, nur aus Spaß wäre private, public usw. eingeführt worden ?

Globale Variablen kommen aus den 50er Jahren des letzten Jahrhunderts (Basic & Co). Da ging es wohl nicht anders. Dann kamen Unterprogramme mit eigenen Variablen. Dann noch das Unit Konzept mit diesen beiden Sorten an Variablen und zusätzlich noch Implementation/Interface-Unterscheidung (auch schon 20 Jahre her). Und jetzt muß man sich sogar noch mit protected, published usw. rumplagen. Warum ist das so ? Weil es nicht anders geht. :mrgreen: Alternative wären unüberschaubare, fehlerträchtige Programme. Deshalb die Frage nach deiner Programmgröße. Wenn ich an 1000 Stellen im Programm immer dasselbe

Delphi-Quellcode:

var i : integer;

benutze und verändere, dann sage mir mal an welcher dieser 1000 Stellen das i irrtümlich falsch besetzt wird. Du wirst ewig brauchen, das zu finden, falls dies überhaupt gelingt.

Guck dir mal in dem Zusammenhang noch GOTO an. Im Zusammenspiel mit globalen Variablen ist das dann echt nicht schlecht. 8)

EDIT : Der letzte Satz ist natürlich ein Witz. Verwende bloß kein GOTO. Und dizzys Beitrag paßt auch gut zum Thema. Schön zu sehen, was bei dabei rauskommt: man kann es nicht mal vernünftig erklären. Ich habe zwar den Sinn verstanden, aber nur weil ich sowieso gewußt habe was er meint. :lol: @dizzy: ich meine damit ein Beispiel zu konstruieren. Sogar ein Beispiel in diesem Zusammenhang ist irreführend, egal wie mans anpackt.

[new4toms]

Zitat:

Zitat von Hansa

Zitat:

Zitat von new4toms

...Bislang hatte ich noch nie Probleme, meinen eigenen Sourcecode wiederzuerkennen.

Womit haben denn die "Globalen-Variablen-Feinde" Probleme?

Da du ja angeblich bereits alles darüber gelesen hast, müßte dir einiges klar sein, warum das keiner machen sollte. Einzeln zähle ich das deshalb jetzt nicht neu auf. Mehrere Gegenfragen : womit hast denn du Probleme, wenn du glaubst sie benutzen zu müssen ? Wie groß ist denn dein Programm überhaupt ? Meinst du, nur aus Spaß wäre private, public usw. eingeführt worden ?

Globale Variablen kommen aus den 50er Jahren des letzten Jahrhunderts (Basic & Co). Da ging es wohl nicht anders. Dann kamen Unterprogramme mit eigenen Variablen. Dann noch das Unit Konzept mit diesen beiden Sorten an Variablen und zusätzlich noch Implementation/Interface-Unterscheidung (auch schon 20 Jahre her). Und jetzt muß man sich sogar noch mit protected, published usw. rumplagen. Warum ist das so ? Weil es nicht anders geht. :mrgreen: Alternative wären unüberschaubare, fehlerträchtige Programme. Deshalb die Frage nach deiner Programmgröße. Wenn ich an 1000 Stellen im Programm immer dasselbe

Delphi-Quellcode:

var i : integer;

benutze und verändere, dann sage mir mal an welcher dieser 1000 Stellen das i irrtümlich falsch besetzt wird. Du wirst ewig brauchen, das zu finden, falls dies überhaupt gelingt.

Guck dir mal in dem Zusammenhang noch GOTO an. Im Zusammenspiel mit globalen Variablen ist das dann echt nicht schlecht. 8)

EDIT : Der letzte Satz ist natürlich ein Witz. Verwende bloß kein GOTO. Und dizzys Beitrag paßt auch gut zum Thema. Schön zu sehen, was bei dabei rauskommt: man kann es nicht mal vernünftig erklären. Ich habe zwar den Sinn verstanden, aber nur weil ich sowieso gewußt habe was er meint. :lol: @dizzy: ich meine damit ein Beispiel zu konstruieren. Sogar ein Beispiel in diesem Zusammenhang ist irreführend, egal wie mans anpackt.

@Hansa: Das Projekt ist/sind ca. 200.000 Zeilen, die ich "verschärft" betreue. Ca. 15.000 Programmzeilen davon wurden von mir im Lauf der letzten sechs Jahre modifiziert (mit globalen Variablen und sogar GOTOs). Mit allen benutzten Komponenten sinds sogar über 1.4 MIO Zeilen, die ich für das Projekt (D5pro) betreue/überwache! Da ich dabei selbstverständlich ein Schweinegeld verdiene, darfst Du mal an dem Bentley lutschen, den ich Hartz IVer gerade poliere :-)

Edit:
i: Integer (local);
gi: Integer (global_integer);
gi2: Integer (global_integer_#2);
b: Boolean (local);
gb: Boolean (global_boolean);
gb2: Boolean (global_boolean_#2);

Natürlich bin ich mir *absolut* sicher, daß man die obige Reihe keinesfalls fortsetzen kann, da sie keinerlei Systematik erkennen lässt!!!

Man sieht sich wieder bei HartzIV!?

[Pseudemys Nelsoni]

Mal ne Frage @new4toms:

Wieso packst du diese ganzen globalen Variablen nicht einfach in den privaten Abschnitt deiner TForm1(?)-Klasse?

[Robert Marquardt]

Globale Variablen, die nicht fuer die ganze Lebenszeit der Unit gebraucht werden, machen unnoetige Probleme.
Das groesste Problem ist, das man die Variable zugreifen kann, obwohl sie eigentlcih ungueltig ist.
Sprich man gibt die Fehlermeldung auf, die man sonst bekommen koennte.

Was man sihc mit globalen Hilfsvariablen auch einfangen kann sind Probleme mit der Nebenlaeufigkeit.
Eine Hilfsvariable kann durchaus von mehreren Instanzen einer Komponente zugegriffen werden und schwupps aendert die eine die
Variable waehrend die andere auf die Werte vertraut.

Bei der JVCL z. B. habe ich alle globalen Variablen (und als Variablen missbrauchte Konstanten) entfernt, die nicht
wirklich global sind. Zusaetzlich wurden alle globalen Variablen (meist Listen) in der finalization nicht nur
freigegeben sondern auch auf nil gesetzt. Das hat eine Menge merkwuerdiger Fehler beseitigt.

[alzaimar]

Ich finde die Diskussion hier insofern etwas lustig, als das Delphi selbst globale Variablen kreiert.

Es geht natürlich Ohne.
Es geht auch ohne Goto-Befehle.
Es geht auch alles nur mit OOP.

Das ist aber genauso hirnrissig und engstirnig, als zu behaupten, alles ginge mit ASM.

Manchmal sind globale Variablen praktischer, weil sie eben Global sind. Wozu soll ich sie in eine Klasse schmeissen? Wenn ich aber recht drüber nachdenke, ist das reine Faulheit... :oops:

Goto: Es gibt wirklich Anwendungsfälle, bei denen ein Goto einfach eleganter, weil schneller, ist. Allerdings nimmt die Anzahl der Argumente seit 'break' und 'continue' rapide ab. Aber mal im Ernst, sind die beiden Befehle nicht einfach nur GOTO's aber im hübscheren Gewand?

OOP: Das ist schon eine feine Sache, aber für kleine Geschichten einfach überdimensioniert. Ich brech mir bei einem 100 Zeilen Teil doch nicht Einen ab und erzeuge erst eine Klasse...

----
Ich denke, es wird klar, woraum ich hinaus will: Man sollte seine Werkzeuge sorgfältig aussuchen und genau den Bedürfnissen entsprechend einsetzen:

Wenn's die Performance verlangt, hüpfe ich in meinen Code mit GOTO's (ordendlich dokumentiert) durch die Gegend.

OOP setze ich natürlich weitestgehend ein, aber auch nicht für jeden Furz.

[jfheins]

Ich finde, man sollte nicht alles gleich verurteilen.

Man kann GoTo's und globale variablen durchaus sinvoll verwenden,
wenn ein GoTo sinvoller und einfacher zu verstehen als eine Schleife ist, warum nicht verwenden ?

Man kann auch globale Variablen sinnvoll einsetzen, nur kann man den gleichen Effekt meist mit einer Klassenvariable erzielen, wobei hier eben die OOP-Lösung vorzuziehen ist.

[Hansa]

Ich habe nicht gesagt, man dürfe keine globalen Variablen benutzen. Es geht darum, sie weitestgehend zu vermeiden. Manchmal geht es eben nicht anders. Bsp.: Variable wird im ganzen Programm gebraucht. Diese kommt aber aus einer INI. Man kann also leider nicht mal eine Konstante verwenden.

Dann noch zu den GOTOs (wenn man hier einmal ein falsches Wort benutzt, schon kommen die Geier) :mrgreen: : das war nichts anderes als ein Zugeständnis in den 70ern an die Basic-Umsteiger. Wer die benutzt, obwohl er sie gar nicht benötigt, der ist entweder grenzenlos faul oder kann schlicht und einfach nicht programmieren, weil damit Delphi so ziemlich vollständig ausgehebelt werden kann.

[alzaimar]

Zu den GOTOen (um mal noch eine Veranglizistisierungsverklausulierung vorzunehmen):
Lasst uns das folgende Gesetz im Bundestag einbringen:

Zitat:

Wer GOTOen benutzt oder erwähnt oder benutzte oder erwähnte GOTOen in Umlauf bringt wird präventiv geteert und gefedert. Wenn er sich anschliessend traut, sein GOTO zu begründen, sei ihm verziehen. Wenn nicht, kriegt er gleicht noch eins drauf.

Einverstanden?

[Phoenix]

Natürlich haben globale Werte ihren Sinn:

Man denke nur an Pi, die Eulersche Zahl, die Konstante c (Lichtgeschwindigleit)...
Okay, das sind alles Konstanten.

Globale Variablen... ja. Auch: Zum Beispiel die Gravitationskraft an der aktuellen Position. Die muss einmalig berechnet werden (daher Variable), ist dann aber zumindest für die Programmlaufzeit über konstant.

Aber schon das Beispiel ist sehr konstruiert, genauso konstruiert wie andere Anwendungsbeispiele mit global verwendeten Variablen.

Die richtige Lösung? Ganz einfach: Ein Objekt, welches die 'globalen' Werte zur Verfügung stellt. Zu holen als Singleton über eine Object-Factory. Es bietet sich z.B. der Name Globals an. Alle Variablen die man wirklich überall braucht werden als Properties dieser Klasse deklariert und gut ist: Keine Namensverwirrung mehr, kein versehentlicher falscher Zugriff mehr.

[Robert_G]

Der einzige Anwenugsfall von globalen Variablen, der mir gerade einfällt sind die besprochenen Singletons.
Da es in Delphi32 keine statischen Felder/Properties gibt muss man also eine Instanz in einer globalen Variable halten.
Wobei diese natürlich im implementation-Teil deklariert wird und somit außerhalb der Unit dieser Klasse nicht zu sehen ist.

Sonst sehe ich keinerlei Sinn und Zweck hinter globalen Variablen. Ich lösche sie auch aus den Formularen raus. Diese Formularvariablen zu benutzen wäre schließlich genauso unsauber, wie eigene globale Variablen überall hinzuschleppen...

[faux]

Mal eine (dumme) Frage:

Was versteht ihr genau unter globale Variable? Nur den im var im interface? Oder auch den private und pubic - Bereich des Formulars?
Also ich benutzen den var-Teil des Interfaces absolut NIE, denn das blockiert ja dann alle gleichnamigen Elemente und sieht außerdem hässlich aus...

[runger]

Hallo,

was versteht ihr denn eigentlich unter globalen Variablen?

Folgende Vorgehensweise:
Es existieren vollständig gekapselte Eingabefenster ( mehr als 100). ( Machen wir so )
In den Fenstern werden alle Eingaben auf untere und obere Grenze und andere Dinge gecheckt.
Es gibt für jedes Formular eine ( für die Daten ) Eingangsprozedur und eine Ausgangsprozedur.
Das ist OOP in Reinkultur.
Wir benutzen globale Variable als Zwischenspeicher um unsere Daten nachher über einen pre und post Prozess ( Umwandlung in Hex ode rzurück ) an die Unterstation zu senden oder die Informationen zu holen.

Was ist daran unseriös? Blödsinnig ist natürlich diese globalen Variablen über sämtliche Units zu verteilen. Sie sind selbstverständlich in einer Unit konzentriert.
Dieses Verfahren ist absolut übersichtlich. Wir können unseren Code auch nach 10 jahren noch lesen.

Rainer

[Hansa]

Genau so siehts aus ! Es gibt wenige Ausnahmen. Aber das hier :

Zitat:

Zitat von Robert_G

Wobei diese natürlich im implementation-Teil deklariert wird und somit außerhalb der Unit dieser Klasse nicht zu sehen ist.

Diese Quasi-Konstanten, wie die aus meiner INI, die brauche ich an allen Ecken und Kanten. Die kann ich doch nicht für andere Units unsichtbar machen. Oder wie ist das gemeint ? Also meine paar echt globalen Variablen, die sind so benannt, daß da eigentlich nichts passieren kann. Weiß nicht, ob es sich lohnt da überhaupt etwas dran zu machen.

[Robert_G]

Zitat:

Zitat von faux

Mal eine (dumme) Frage:

Was versteht ihr genau unter globale Variable? Nur den im var im interface? Oder auch den private und pubic - Bereich des Formulars?

Ein Formular ist eine Klasse. "Variablen", die du dort deklarierst sind Felder und können aufgrund ihrer Verknüpfung zur Instanz dieser Klasse keine Probleme machen. Jedenfalls nicht die, die man sich aus Faulheit/Unwissenheit mit globalen Variablen einhandelt.

Demnach wären alle Variablen, die nicht Felder einer Klasse (oder eines Records :? ) bzw. lokale Variablen einer Methode sind, globale Variablen. ;)

[Speedmaster]

Verstehe es auch nicht, in manchen fällen sind Globale Variablen wichtig.
Z.b. habe ich eine Logunit( Erstellt Log Dateien ), diese musste ich als Globale Variable behandeln um von überall zugreifen zu können.

Sonst braucht man sie nicht, und würden das Programm nur unübersichtlich machen!

[Robert_G]

@SpeedMaster
Hier ist schon 2-mal das Wort Singleton gefallen. Das wäre eine Möglichkeit es zu lösen.
Die andere wäre, nach außen die Funktionalität über class methods anzubieten und eine Singleton nur innerhalb der implmentation zu halten.
(Denn ein normales Singleton kannst du zerstören!)

[Pseudemys Nelsoni]

Zitat:

Verstehe es auch nicht, in manchen fällen sind Globale Variablen wichtig.
Z.b. habe ich eine Logunit( Erstellt Log Dateien ), diese musste ich als Globale Variable behandeln um von überall zugreifen zu können.

Und was hindert dich daran diese Variable in deine TForm1-Klasse zu packen und (wenn nötig) von ausserhalb der unit mit Form1.var drauf zuzugreifen? (Sofern unit1, im implementationsteil der anderen Unit...)

[Robert_G]

Zitat:

Zitat von Pseudemys Nelsoni

Zitat:

Verstehe es auch nicht, in manchen fällen sind Globale Variablen wichtig.
Z.b. habe ich eine Logunit( Erstellt Log Dateien ), diese musste ich als Globale Variable behandeln um von überall zugreifen zu können.

Und was hindert dich daran diese Variable in deine TForm1-Klasse zu packen und (wenn nötig) von ausserhalb der unit mit Form1.var drauf zuzugreifen? (Sofern unit1, im implementationsteil der anderen Unit...)

:shock: Du willst wohl Feuer mit Feuer bekämpfen? Was glaubst du wohl, was Form1 wäre? Eine nicht-globale Nicht-Variable? :roll:

[Pseudemys Nelsoni]

jo Robert, klar ist Form1 eine globale Variable, aber das kann man wohl kaum ändern.
Ausserdem wäre damit sichergestellt, das man eben nur mit expliziter Angabe von Form1. auf die Variable zugreifen kann. (Ausserhalb der Klasse)

[Delphi_Fanatic]

Natürlich machen globale Variablen Sinn !

Wenn eine Variable "Unit-übergreifend" benötigt wird und an jeder Stelle des Programms zu jederzeit
verfügbar sein soll - dann muss diese Variable einfach global sein.

Und dann erreicht man mit irgendwelchem Spielkram wie dem hier :

Zitat:

Die richtige Lösung? Ganz einfach: Ein Objekt, welches die 'globalen' Werte zur Verfügung stellt. Zu holen als Singleton über eine Object-Factory

... auch keinen wirklich spürbaren Vorteil.

Objektorientierte Programmierung in allen Ehren, aber bitte dort, wo es auch wirklich Sinn macht und spürbare Vorteile
bringt.

Und normalerweise treten dann auch keine ...

Zitat:

Namensverwirrung (...) versehentlicher falscher Zugriff (...)

... auf, denn es liegt in "der Natur der Sache", dass solche globalen Variablen in der Regel eben auch eine eindeutige
und unverwechelbare Bedeutung haben.

Aber natürlich sollte man eben keine Laufvariablen oder irgendwelche Zählvariablen oder Ähnliches global definieren.

[SirThornberry]

Grundsätzlich ist es möglich ohne globale Variablen auszukommen. Delphi selbst benutzt zwar auch globale Variable, aber auch diese könnte man vermeiden.

Zum Beispiel ist bei der VCL-Programmierung das zuerst kreirte Form immer das MainForm. Dementsprechend könnte man nach oop, Form2, Form3 als Public in Form1 deklarieren (und schon wären diese Globalen Weg). Dann gäbe es noch Form1. Wenn Borland die Objectorientierung bei Delphi aber zu 100% umsetzen würde wäre Form1 vermutlich im Public von TAppplicaiton. Und die Globale "Application" würde auch nicht wirklich benötigt werden weil es auch so ginge

Delphi-Quellcode:

TApplication.Create;

und beim Klick auf schließen könnte die Instanz von TApplication sich selbst zerstören

Delphi-Quellcode:

procedure TApplication.CloseClick;
begin
  Self.Free;
end;

Leider (oder für manche zum Glück) hat Borland das nicht so umgesetzt. Jedoch ist es auch mit den aktuell in Umlauf befindlichen Delphis möglich das alle Globalen einfach Public-Variablen vom Mainform sind.

Zum Beispiel Pi etc.: Wer wirklich Objectorientiert arbeiten will kann auch solche Variablen ins Public des Mainforms packen.

Ohne Frage ist dies alles aber auch ein riesen Aufwand und für kleinere (Mini-)Projekte overkill. Wie schon mehrfach in dem Thread erwähnt sollte man deshalb abwägen wann man was verwendet.

Zur Ausgangsfrage: Keine(möglichst wenig) globalen Variablen weil:
- Ich habe ein Programm in dem sich ein Button befindet. Wenn dieser Button jetzt einen Darstellungsfehler hat finde ich den Fehler bedeutend schneller wenn ich weiß das sich dieser irgendwo innerhalb von "TKomischerButton" befindet. Würden jetzt aber alle funktionen innerhalb des Buttons auf globale Funktionen/Variablen zugreifen so müsste ich befürchten das ich mit der Beseitigung des Bugs im Button, Bugs in anderen Komponenten verursachen welche mit der falschen Globalen Variablen/Funktion richtig gearbeitet haben.
Auch Ableitungen von klassen sind nicht möglich/so einfach wenn ich keine Funktion überschreiben kann weil sie global ist...

[Phoenix]

Zitat:

Zitat von SirThornberry

Zum Beispiel Pi etc.: Wer wirklich Objectorientiert arbeiten will kann auch solche Variablen ins Public des Mainforms packen.

Eine Variable hat hier den grossen Vorteil das man das leicht anpassen kann, sollte sich der Wert von Pi mal ändern :lol:

Nee, jetzt mal ehrlich: Pi ist eine Konstante, und die darf natürlich global in einer Unit deklariert sein. Ich packe alle Konstanten immer in entsprechende Units und wo ich die Konstanten brauche nehm ich die Unit zur Hand.

Aber mir fällt ganz ehrlich kein einziges Beispiel ein, wo es korrekt wäre eine globale Variable herzunehmen. Und ich bin da schon eine ganze Weile am grübeln. Nichts was mir einfällt ist eine globale Variable. Die ganzen Werte haben irgendwie immer einen Zusammenhang und gehören von daher in ein Objekt.

Zur Implementierung von Singletons: Ich lege solche Objekte immer in unitlokalen Variablen ab. Daher kann ich die auch im finalization-Teil aufräumen wenn das Programm beendet wird und notfalls sogar im initialization bereits erzeugen wenn sie immer da sein müssen. Im Normalfall werden die Objekte aber erst beim ersten Zugriff erzeugt.

[SirThornberry]

Ich weiß, pi war ein schlechtes Beispiel, ich meinte eigentlich den Fall mit der Gravitation (was hier in dem Thread irgendwo erwähnt war), nur wusste ich leider nicht wie man das schreibt und habs auch nicht mehr gefunden. Aber: Pi ist zwar eine konstante aber wenn man wöllte könnte man diese Trotzdem im MainForm oder in "TConstants" deklarieren und dort im Create staatich zuweisen. (wobei ich bei Konstanten die Globalisierung noch einsehe)

[marabu]

Der weitgehende Verzicht auf globale Variablen alleine erhöht kaum die Qualität eines Programms. Die Eliminierung von globalen Variablen, die gar keine sind, ist das Ziel - getreu dem Grundsatz des information hiding. Wer dabei über das Ziel hinaus schießt, der liegt auch daneben. Gäbe es keine globalen Variablen, dann müsste man sie erfinden.

Wer mit Delphi qualitativ hochwertige Programme erstellen will, der kommt um das Studium einschlägiger Fachliteratur nicht herum. Alleine das Kapitel "Sichtbarkeit von Variablen in prozeduralen Sprachen mit Blockkonzept" - dazu zählen alle Pascal Dialekte, aber auch Ada - verschafft wertvolles Grundlagenwissen und erübrigt manchen unfreiwillig komischen Beitrag - was aber manchmal auch wieder schade wäre.

Keiner muss sich einem Hochschulstudium der Informatik unterziehen, nicht einmal ein FH-Studium ist notwendig, um vernünftige Programme zu schreiben. Wer aber - als Gegner oder Befürworter von globalen Variablen - auch nach etlicher Zeit glaubt Maximal-Forderungen durchsetzen zu können, der braucht dringend Hilfe.

Grüße vom marabu

[alzaimar]

Was DU als 'Unit Globals' implementiert hast, ist ja nichts anderes als ein Datenmodul. Nur eben als Unit. Die ganze Diskussion pro/contra OOP ist sowieso irgendwann überflüssig, weil ja OOP nichts anderes als eine andere Sichtweise ein und derselben Geschichte ist.

Ob ich nun eine Methode "foo.bar (huhu)" habe, oder eine Prozedur "foo (bar, huu)" ist ein und das Selbe. Aber mit OOP (und dieser Verberbungsgeschichte) bekomme ich Struktur in meine Anwendung und werde gezwungen, semantisch zusammenhängende Abläufe und die Elementaroperationen auf den Daten auch in eine Unit/Klasse zu schreiben.

So gesehen, ist C das Grauen, Pascal mit dem Unit-Konzept schon besser, Modula noch ein wenig restriktiver, Delphi schon ganz brauchbar, und C#/Java total OOP-lastig. Wie weit man sich an C (C steht für Chaos, he he) oder Java gebunden fühlt, ist eine Glaubensfrage.

Ich persönlich finde, dsa Delphi einen gesunden Mittelweg beschreitet, weil es den Spagat von Chaos zu OOP schafft, und mir trotzdem meine Freiräume lässt. Alles eine Frage des Glaubens.

Was man aber unabhängig von seinem Glauben machen sollte, ist anständigen, rechtschaffenen (ja ja und vaterlandsliebenden, regierungstreuen, chrr..chrr..) Code zu schreiben, der jedem Review standhält. Wenn man so diszipliniert ist, bekommt man auch ASM-Code mit globalen Variablen so hin, das er noch nach 10 Jahren lesbar ist. Alles eine Frage des Könnens.

Na denn. Nobody is perfect.

@Marabu: Dein Beitrag kam gerade eben, aber trifft ins Schwarze!

[SubData]

In einer meiner Anwendungen wird zur Startzeit eine Pfad-Angabe aus einer INI eingelesen, die dann zur kompletten Laufzeit immer wieder für Datenbankverbindung verwendet wird.

Und jetzt hätte ich gerne ein gutes Argument, warum ich das nich mit ner globalen Variable machen soll :mrgreen:

[Steve]

Hi,

bei mir kommen die Einstellungen, die ich aus den INIs les, in ne eigene Klasse, welche die Variablen hält. Die Klasse kümmert sich auch ums speichern, laden usw.
Auf ein solches Objekt und dessen Eigenschaften kann ich auch von überall zugreifen :)
Aber wie hier nun schon x-mal erwähnt: kommt auf den Einzelfall an.

Gruß
Stephan :dance:

[SubData]

Joa....

Hab nämlich irgendwie keine Lust für gerade mal 2 Nur-Lesen Variablen auch noch Klasse anzulegen ...
Die Variablen werden wärend der Laufzeit noch nichmal geändert -g-

[alcaeus]

Zitat:

Zitat von SubData

Die Variablen werden wärend der Laufzeit noch nichmal geändert -g-

Na dann waere eine Options-Klasse mit readonly-Properties genau das richtige. So verhinderst du auch zufaelliges Ueberschreiben der Werte ;)
Ausserdem koennte deine Klasse das Laden und Speichern uebernehmen ;)
Fuer mich ist sowas Geschmacksache, ich habe in den letzten Wochen angefangen, alles in Klassen zu verpacken ;)

Greetz
alcaeus

[Delphi_Fanatic]

Zitat:

So verhinderst du auch zufaelliges Ueberschreiben der Werte

Sagt mal, Leute, was habt Ihr hier in diesem Thread eigentlich andauernd mit Euren "versehentlichem" oder "zufälligem" Überschreiben irgendwelcher Werte ?

:?:

Man wird doch wohl als auch nur halbwegs erfahrener Programmierer kontrollieren können, WANN man WO WELCHE Werte hinschreibt.

Aber jetzt deswegen eine eigene Klasse / Objekt zu definieren, nur weil man befürchtet, man könne irgendwann versehentlich
mal eine Varibale überklatschen ... das ist schon wirklich eine etwas merkwürdige Vorgehensweise.

Zitat:

Ausserdem koennte deine Klasse das Laden und Speichern uebernehmen

Vielleicht könnte das Sinn machen bei etwas spezielleren Sachen, meinetwegen wenn er z.B. eine StringList in eine Ini-Datei kriegen muss oder so... aber wenn die Variablen nur irgendwelche Standard-Formate haben, meinetwegen Strings oder Integers ... wo sollte dann der Vorteil einer eigenen Klasse gegenüber einem normalen
<myinifile>.WriteString / <myinifile>.WriteInteger liegen ?

[Luckie]

Zitat:

Zitat von Delphi_Fanatic

Man wird doch wohl als auch nur halbwegs erfahrener Programmierer kontrollieren können, WANN man WO WELCHE Werte hinschreibt.

Als einzelner Entwickler an einem übersichtlichen, kleinen Projekt vielleicht, aber wenn du vier oder mehr Units hast und zu dritt an dem Projekt arbeitest, passiert das ganz schnell. Und dann viel Spass bei der Fehlersuche, wenn du dich noch durch die Unis der anderen Programmierer durchwühlen darfst.

[Robert Marquardt]

Hast du schon mal ein Projekt mit mehreren Entwicklern gemacht?
Versehentliches Ueberschreiben kommt auch vor wenn man eine Hilfsvariable fuer eine Komponente global anlegt und dann
nur mit einer Instanz der Komponente testet. Der gleichzeitige Zugriff bleibt dann ungetestet.
Dies ist ein haeufiger Fehler, der auch dir passieren kann. Du zeigst mit deinen Formulierungen nicht deine Befaehigugung sondern deine Unerfahrenheit.

[Speedmaster]

Globale Variablen nicht zu verwenden ist IMHO großer Schwachsinn, wie willst du den sonst z.b. dass Sinnvolle Arbeiten mit Log Dateien realisieren??

Und zum Thema Werte überschreiben:
Wenn Werte überschrieben werden zeugt das nur davon das das Projekt nicht durchdacht ist, und kein Standart da ist.
Ich z.b. gebe wenn ich eine Globale Variable benutze, ihr immer den Namen der Klasse minus das "T".

Wenn das Programm richtig Strukturiert ist braucht man Klassen nur einmal Global, sonst eben Lokal in einer Klasse, wobei man dort eventuelle Probleme einfach lößen kann indem man z.b. ein "v" vor jede Variable setzt die nur in dieser Klasse benutz wird!

[Delphi_Fanatic]

Zitat:

aber wenn du vier oder mehr Units hast und zu dritt an dem Projekt arbeitest, passiert das ganz schnell.

Tatsächlich ? Also ich arbeite hier mit 4 weiteren Kollegen an einem Projekt das 90 Formulare und ca. 140 Units (also reine *.pas-Dateien ohne dfm) hat und solche Probleme mit versehentlichem Überschreiben irgendwelcher globaler Variablen sind mir völlig fremd.
Wie gesagt - OOP in allen Ehren, es geht gar nicht OHNE, aber man muss solche Konzepte nun auch nicht auf Krampf irgendwo
rein drängen, wo man damit eigentlich gar nichts damit vereinfacht und wo man damit auch nirgendswo die Pflegbarkeit / Lesbarkeit / Qualität des Quelltextes erhöht.

[Delphi_Fanatic]

Zitat:

Wenn Werte überschrieben werden zeugt das nur davon das das Projekt nicht durchdacht ist, und kein Standart da ist

Dem schliesse ich mich voll und ganz an !
Wie "qualitativ hochwertig" und leicht pflegbar ein Quelltext ist - das hängt viel mehr von der allgemeinen
Anwendungsarchitektur ab und vor allem auch davon , ob und welche Programmier-Standards- und Richtlinien man vorher festgelegt hat.

[Luckie]

Zitat:

Zitat von Speedmaster

Globale Variablen nicht zu verwenden ist IMHO großer Schwachsinn, wie willst du den sonst z.b. dass Sinnvolle Arbeiten mit Log Dateien realisieren??

Wenn du dafür eine globale variable brauchst, machst du definitiv was falsch oder hast das Prinzip von OOP nicht verstanden.

[Robert_G]

Jetzt konnte ich' doch nicht lassen... :?

Zitat:

Zitat von Speedmaster

Globale Variablen nicht zu verwenden ist IMHO großer Schwachsinn, wie willst du den sonst z.b. dass Sinnvolle Arbeiten mit Log Dateien realisieren??

Habe ich oben geschrieben.

Zitat:

Zitat von Speedmaster

Und zum Thema Werte überschreiben:
Wenn Werte überschrieben werden zeugt das nur davon das das Projekt nicht durchdacht ist, und kein Standart da ist.
Ich z.b. gebe wenn ich eine Globale Variable benutze, ihr immer den Namen der Klasse minus das "T".

Komisch... Wisst ihr überhaupt wie es zu dem T kam?
Wenn du in einer klasse eine Property mit einer bestimmten anderen Klasse haben willst ist es nunmal am hübschesten Property und Klasse gleich zu benennen. Da das gegen das Eindeutigkeitsprinzip von Delphi verstößt fügt man dem Typen ein T vorweg. (Es waren wohl Felder von Records und nicht Klassen und Properties, damas vor 200 Jahren, aber die Idee ist die geliche ;) )
Die Properties heißen heißen also wie der Typ ohne das T. Keine Ahnung wo dein Standard herkommt, es ist ganz sicher kein Standard für andere Delphi-Entwickler!

Warum das v als Prefix sinnlos und alles andere als standardkonform ist, brauche ich wohl nicht erwähnen, oder?

Zitat:

Zitat von SubData

Hab nämlich irgendwie keine Lust für gerade mal 2 Nur-Lesen Variablen auch noch Klasse anzulegen ...

Hmm... Schonmal von Vererbung und Polymorphy gehört? :gruebel:
Damit kann man nämlich prima Dinge wiederverwenden ohne sie immer wieder neuerfinden zu müssen.

Ich hättte keinen Bock überall den Zustand dieser Variable zu prüfen. Ich müsste es aber machen, da Ich in gewisser Weise defensiv, und somit fehlervorbeugend, programmieren muss.

@Delphi Fanatic
Meine Packages werden auch von anderen benutzt so wie ich Packages anderer benutze. ( Das traf zumindest auf meine berufliche Win32-Zeit zu, .Net kennt ja zum Glück keine globalen Variablen und lose Funktionen mehr :zwinker: )

Wo kommt man denn hin, wenn Entwickler A einfach so eine globale Variable einführt, weil er zu faul oder zu unfähig ist um es richtig zu machen, auf die ICH nun überall achten muss, weil es eben keinen Kompilierfehler/Laufzeit fehler gibt, wenn ich in einer dummen Situation darauf zugreife.
Die von dir als Spielkram bezeichnete Factory kann nämlich auch verwendet werden um eine Exception in einer dummen Situation auszulösen. Dann merke ich sofort, dass ich da Käse fabriziert habe. ;)
Der Spielkram kann auch automatisch, beim ersten Zugriff, im Hintergrund die INI laden.
Der Spielkram könnte problemlos angepasst werden um ein Neuladen zu bewirken, wenn die Datei in der zwischenzeit geändert wurde.
Der Spielkram versteckt das INI-File vor dem Rest der Applikation, auf die Art könntest du das altmodische INI-File problemlos gegen zm Bsp. eine XML Datei austauschen. OHNE dass sich für den Rest der Applikation auch nur irgendwas ändert.
Der Spielkram könnte auch eine Interface instanz zurückliefern (was er wahrscheinlich sowieso machen würde ;) ), diese kann man auch nicht so einfach zerstören.

Das waren jetzt nur ein paar Argumente, die einfach aufzeigen sollen, dass sich Faulheit beim Programmieren nicht auszahlt.
Was du einmal an ein paar Codezeilen und etwas Designzeit "verschwendest" bekommst du zig-fach zurück, da du eben keinen statischen, fehlerträchtigen und alles mit Bezeichnern überflutentenden "Diät"-Code produzierst. Viele Klassen oder deren Vorgänger wirst du nämlich auch in anderen Projekten wiederverwenden können. Oder innerhalb des gleichen, nur an anderer Stelle.

Modularität ist eine prima Sache, funktioniert aber nur wenn die Logik eines Moduls innerhalb des Moduls bleibt. ;)

[Pseudemys Nelsoni]

Zitat:

Wenn Werte überschrieben werden zeugt das nur davon das das Projekt nicht durchdacht ist, und kein Standart da ist.
Ich z.b. gebe wenn ich eine Globale Variable benutze, ihr immer den Namen der Klasse minus das "T".

Dein Deutsch könnte auch nochmal durchdacht werden :)... Standard

Hat schliesslich nicht mit irgendeiner Art des Stehens zu tun.

@Thema: Ich kann mich da nur Robert anschliessen :mrgreen: