Globale Variablen und OOP

[TankWart]

danke für die vielen Antworten,
es hat mir auf alle Fälle weiter geholfen.

Vielleicht kennt ja noch einer ein gutes Buch zum Thema OOP, vorzugsweise in Delphi,
wo auch beschrieben ist, wie man richtig vorgeht um Wiederverendbaren Quellcode zu schreiben.

Über Webseiten, Scripte, Tutorials,.. freue ich mich auch

mfg
Tankwart

[Luckie]

Tutorial: http://delphitutorials.michael-puff.de

[IngoD7]

@marabu

Das ist sehr schön beschrieben!

[Hansa]

Ingo hat schon Recht ! Wahrscheinlich hat der Fragesteller des öfteren gesehen, dass von globalen Variablen abgeraten wird. Unter anderem von mir auch. Aber das darf man doch nicht dogmatisch sehen. Manchmal fliegen aber tatsächlich die Kanonenkugeln auf Spatzen und es werden, wie angesprochen Properties, Setter usw. verwendet. Auch das ist Anfängerstil, genauso wie an allen Ecken und Kanten globale Variablen zu benutzen.

Was ist denn nun genau zu tun ? Die Faustregel lautet : Sichtbarkeit möglichst klein halten. Also : Variable zumindest mal in der Form halten. Wenns geht in den private Teil. Da gehören sie hin, es sei denn etwas wird vererbt. Variablen auch lokal innerhalb der jeweiligen Prozeduren deklarieren. Ist das gelungen, dann ist schon viel gewonnen. Es ist eben hauptsächlich genau zu überlegen, wo und wann eine Variable gebraucht wird.

Gegenbeispiele für globale Variablen gibts nämlich auch. Beispiel : brauche einen konstanten Wert überall im Programm. Ganz klar : ist eine Konstante. Den Wert kann ich aber trotzdem nicht als CONST deklarieren, weil er vom Einsatzort abhängt und auch geändert werden kann. Der kommt eben aus INI-Datei. Er wird beim Programmstart einmalig gelesen und während der Ausführung des Programmes verwendet. Ich wäre schön blöd, den für jede Form an eine private-Variable zu übergeben oder mich mit Properties oder sonstwie zu verrenken.

wg. roter Kasten : Marabu hat auch Recht. Rest : siehe oben.

[Elvis]

Zitat von IngoD7:

Vorab:
Der Fragesteller fängt - wie es aussieht - doch gerade erst an mit Delphi und OOP; und da würde ich ihm niemals anraten wollen, krampfhaft auf globale Variablen zu verzichten. Für einen Anfänger ist das nämlich ein Krampf (Datenmodule, eigene Klassen, etc.).

Denke ich eher nicht. Gerade Anfänger haben ganz andere Probleme als Forms und DataModules.
Und der krampfhafte Teil kann für den Anfänger eine ganz gute Lehrstunde sein wann es sich denn wirklich lohnt den Weg zu gehen und wann nicht. Wieviel Aufwand es anfangs, einmalig, macht, und wie viel man sich später beim Arbeiten am Projekt spart.
Er kann dann einfach besser einschätzen. ob es sich lohnt einen Notepad-clone hinzuschludern, oder es "richtig" zumachen.

Zitat:

Deshalb schrieb ich ja auch von meinem fehlenden Verständnis für eine Notwendigkeit, auf globale Variablen zu verzichten. Es gibt diese absolute Notwendigkeit nicht.

Regel 1 im Umgang mit Zealots gewisser programmierrelevanter Herangehensweisen: Erwähne nie "notwendig", sonst bekommst du die klassische Antwort: "Was ist denn schon notwendig? ASM? Nö, kannst dir ja auch einen Hex Editor nehmen und dort deine Echsen schreiben".

Zitat:

Dein "Au weia" kannst du dir sparen, es sei denn, du kannst beweisen, die alleinige Weisheit gepachtet zu haben.

Hab' die Urkunde hier irgendwo im Schreibtisch vergraben. Ist aber nicht gepachtet sondern gekauft.

Zitat:

Wieso ist ständig von mehreren Instanzen die Rede??? Dass das alles fein geht, bestreitet doch niemand. Aber wer von mehreren Instanzen spricht, denkt eh nicht mehr an globale Variablen, oder?

Weil Dinge selten schwarz oder weiß sind. Wenn man sich fragt was diese Daten darstellen und wie sie benutzt werden kommen sicherlich unterschiedliche Klassen heraus, die für unterschiedliche andere Stellen im Code interessant sind.
Wichtig ist halt immer, dass Code nur das sieht was er muss und auch nur abhängig ist von Dingen, von denen er abhängig sein muss.
Code, der globale variablen oder Singletons[1] nutzt kann man nicht mal eben erweitern um gewissen Aufgaben parallel (read: multithreaded) zu erledigen. Das war der Teil zu Skalierbarkeit.
Die Frage der Wiederverwendbarkeit stellt sich bei Singletons/globalen variablen wahrscheinlich gar nicht erst.

Zitat:

Ich möchte den sehen, der angefangen ist zu programmieren, ohne globale Variablen benutzt zu haben.

Ich auch und ich wünsche TankWart auch viel Spass mit Delphi, egal welchen Weg er einschlägt.
Nur IMHO muss man sich mit Hansa'schen "passt schon"-Tipps gerade bei Anfängern etwas vorsehen.

[1]die können thread safe gemacht werden, aber die nötigen Sperren fressen dir irgendwann die CPU weg.

[Der_Unwissende]

Hi,
erstmal möchte ich hier dem marabu völlig zustimmen.
In kleinen Projekten werden sich die Konsequenzen der Implementierungs-Entscheidungen doch stark in Grenzen halten. Hier arbeiten häufig nur einzelne Personen dran (die den vollen Überblick über alles haben) und Erweitern/Warten wird auch eher selten der Fall sein (insbesondere würde es die selbe Person übernehmen und das wohl eher in kurzem Abstand zur Veröffentlichung).

Zitat von Hansa:

Gegenbeispiele für globale Variablen gibts nämlich auch. Beispiel : brauche einen konstanten Wert überall im Programm. Ganz klar : ist eine Konstante. Den Wert kann ich aber trotzdem nicht als CONST deklarieren, weil er vom Einsatzort abhängt und auch geändert werden kann. Der kommt eben aus INI-Datei. Er wird beim Programmstart einmalig gelesen und während der Ausführung des Programmes verwendet. Ich wäre schön blöd, den für jede Form an eine private-Variable zu übergeben oder mich mit Properties oder sonstwie zu verrenken.

Na ja, das Beispiel für globale Variablen finde ich ist nicht wirklich gegeben. Natürlich kann man eine globale Variable anlegen, die irgendwann irgendwie mit dem Wert der Ini gefüllt wird. Aber hier hat man dann doch wieder das Beispiel der völlig falsch gewählten Sichtbarkeit. Hier kann jeder aus einer anderen Unit diesen Wert als Variable sehen, also auch verändern. Es gibt also weder eine Garantie dafür, dass ich diesen Wert/ diese Variable falsch benutze und den Wert selbst setze, noch kann ich vor dem Lesen sicherstellen, dass der Wert schon geladen wurde. Natürlich kann ich dies im Initialisierungs-Teil der Unit machen, aber ob das dann eine schöne Lösung ist?
Vorallem lässt sich das ganze (imho) schlecht modellieren.
Der eigentlich Sinn der OOP ist es doch letztlich nicht Objekte zu erstellen oder über Klassen zu sprechen. Ich denke eines der wichtigsten Konzepte der OOP steckt in der Abstraktion. Man kann hier sehr schön abstrakt modellieren und die eigentliche Implementierung bleibt von außen völlig verborgen. Man kennt ebend nur die öffentlichen Schnittstellen und hat aut. austauschbare und wiederverwendbare Teile. Das Wort Teile ist natürlich sehr schwammig, korrekter könnte man hier schon von Komponenten sprechen. Doch dazu möchte ich dann auch gleich sagen, dass eine Komponente (in der Informatik) nichts mit einer bestimmten Vorfahrklasse (z.B. TComponent), nicht mal direkt etwas mit OOP zu tun hat. Man kann aber OOP-Sprachen als Komponenten-Modell auffassen, die Klassen als Komponenten und die Objekte als Komponentenexemplar.
Die Vorteile solcher Komponenten sollten dann auch klar sein, man kennt nur ihre Schnittstellen nach außen und kann eine weitere Komponente einfach aus mehreren anderen Komponenten (und etwas Glue-Code) zusammensetzen. Dieses "Lego-Prinzip" ist sehr mächtig, da man hier jede Komponente gegen eine mit gleicher Schnittstelle austauschen kann, ohne dass dies das restliche Programm verändert.
So ist es dann leicht möglich fremde Komponenten (z.B. zugekauftes Know-How/Expertenwissen) einfach in ein Programm zu integrieren. Ist diese Komponente noch nicht verfügbar, steht aber die Schnittstelle fest, kann man z.B. mit einer Dummy-Komponente (gleiche Schnittstelle aber nur Dummy-Funktionalität) schon am restlichen Programm arbeiten und diesen Dummy später durch die echte Implementierung ersetzen.

Ok, bin etwas vom eigentlichen Thema abgeschweift, was? Na ja, wie bereits gesagt, der marabu hat das eigentlich Wichtige (imho) schon sehr viel besser auf den Punkt gebracht.

Gruß Der Unwissende

[Der_Unwissende]

Zitat von IngoD7:

Ich möchte den sehen, der angefangen ist zu programmieren, ohne globale Variablen benutzt zu haben.

Äh, mir fallen da gleich einige ein. Deswegen hier mal die Frage, ob Du dich auf Delphi oder Programmieren allgemein beziehst?

Nehmen wir zum Beispiel Leute die mit Haskell anfangen (z.B. die Studenten an der FU-Berlin, die noch nicht Programmiert haben und die sollte es dort immernoch geben). In Haskell (funktionale Programmiersprache) sind globale Variablen nur mit Monaden möglich. Monaden erfordern aber schon ein eher fundiertes Basiswissen, hier fangen also jedes Jahr noch Leute an zu programmieren ohne eine globale Variable zu verwenden.
Aber auch Java-Programmierer haben das Problem, dass es keine globalen Variablen gibt. Hier können Variablen nur in Klassen deklariert werden. Diese Variablen können natürlich Klassenvariablen sein (sind dann statisch). Es dürfte noch sehr viele weitere Sprachen geben, wo es schon technisch nicht möglich ist.

Für die Sprachen in denen es möglich ist (z.B. Delphi, denke Du beziehst dich darauf), würde ich nicht pauschal ausschließne, dass jmd. auch ganz ohne globale Variablen anfing. Immerhin kommt es hier doch eher auf die Lehre an. Wird Dir nur das Konzept der OOP erklärt... Allerdings halte ich es auch für eher unwahrscheinlich und äusserst selten, dass jmd. hier eine Einführung ganz ohne globale Variablen bekommt/diese nicht verwendet.

[Hansa]

Zitat von Der_Unwissende:

Na ja, das Beispiel für globale Variablen finde ich ist nicht wirklich gegeben...Aber hier hat man dann doch wieder das Beispiel der völlig falsch gewählten Sichtbarkeit. Hier kann jeder aus einer anderen Unit diesen Wert als Variable sehen, also auch verändern...

Da wird aber nichts verändert. Beim Programmstart lesen und das wars. Wer bei so einer trivialen Geschichte noch immer was verkehrt macht, der soll besser nicht anfangen zu programmieren. Oder er soll sein Programm mit überflüssigem DAP-SchnickSchnack zumüllen.

[sirius]

Zitat von Der_Unwissende:

Zitat von IngoD7:

Ich möchte den sehen, der angefangen ist zu programmieren, ohne globale Variablen benutzt zu haben.

Äh, mir fallen da gleich einige ein. Deswegen hier mal die Frage, ob Du dich auf Delphi oder Programmieren allgemein beziehst?

Tja, Ingo, wie du siehst: Die Zeit schreitet voran und du bist auch nicht mehr der Jüngste
Heute, wo man sogar schon in Delphi mit dem Button "Neu" gleich die erste Klasse (TForm1) hingeklatscht bekommt, kann man schon als Neuling komplett und einfach ohne globale Variablen programmieren. Und von den mittlerweile zahlreichen reinen Objektsprachen brauchen wir ja gar nicht reden.
Früher, unter Turbo Pascal, wo man sich zu Beginn seines Programmes erstmal einen globalen Variablenpool zurecht gelegt hat, wo OOP noch ein Vision (um nicht zu sagen eine TVision) war......

Heute kann man als Anfänger sich gleich mal prinzipiell daran gewöhnen, alle Variablen in die Formularinstanz zu legen. Schaden tut dies nicht.

[OT]
Edit: Wenn man es so sieht, erscheint ja TVision vor einem ganz anderen Hintergrund.
[/OT]

[Der_Unwissende]

Zitat von Hansa:

Da wird aber nichts verändert. Beim Programmstart lesen und das wars. Wer bei so einer trivialen Geschichte noch immer was verkehrt macht, der soll besser nicht anfangen zu programmieren. Oder er soll sein Programm mit überflüssigem DAP-SchnickSchnack zumüllen.

Ok, so eine pauschale Aussage ist natürlich ein gutes Argument, aber egal.
Natürlich, gibt es eine globale Variable die nur gelesen werden soll, dann wird das ja auch jeder tun. Wer das anders macht, der hört einfach mit dem Programmieren auf, bin mal gespannt wie gefragt dann Programmierer bald wieder sein werden. Die Idee der unterschiedlichen Sichtbarkeit verschiedener Methoden und Variablen erhielt doch nicht grundlos einzug in einige Sprachen. Also soweit ich das beurteilen kann, wird schnell alles falsch gemacht, was man falsch machen kann. Natürlich nicht alles, aber unter Zeitdruck schleichen sich dann doch schneller kleine Unsauberheiten ein und die führen dann zu Fehlern und die sorgen wiederum für Kosten. Kann mir nicht vorstellen, dass Du noch nicht die Erfahrung gemacht hast, dass Konsequenz immer Priorität haben sollte. Eine solche Ausnahme (für einen sehr konstruiert einfachen Fall) führt schnell zu einer Zweiten und Dritten und dann hat man wieder die Probleme, dass sich jmd. falsch merkt (nie nachliest) dass ein paar der Variablen nur gelesen werden sollen. Da dürfte das Finden eines solchen Fehlers doch deutlich den Aufwand einer sauberen Implementierung überwiegen. Natürlich bedarf es in einem solchen Fall noch lange nicht einem Objekt, aber eine "globale" Funktion, die einfach nur diesen Wert zurückgibt und eine nicht für jeden sichtbare Variable sollten doch um einiges sauberer und sicherer sein (und ganz ehrlich, ich sehe in Sicherheit vor so leicht vermeidbaren Fehlern nichts überflüssiges).

[Add]

Zitat von sirius:

Heute, wo man sogar schon in Delphi mit dem Button "Neu" gleich die erste Klasse (TForm1) hingeklatscht bekommt, kann man schon als Neuling komplett und einfach ohne globale Variablen programmieren.

Wobei man hier natürlich eine automatisch erzeugte globale Varialbe (var Form1: TForm1) bekommt, die Frage ist also programmiert man wirklich ohne?
[/Add]