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

[Delphi_Fanatic]

( @ Robert_G : Ich hab' ja die "Vorzüge" von OOP gar nicht in Frage gestellt, nur ist es aus meiner Sicht trotzdem Unsinn,
jegliche Verwendung globaler Variablen grundsätzlich auszuschliessen. Es ist keine "Programmierer-Todsünde", so wie
z.B. die Verwendung von "Goto's".

und vor allem ist es Unsinn wg. irgendetwas Objekte anzulegen mit der Absicht, so ein "versehenliches" oder "zufälliges"
Überschreiben von Variablen zu verhindern.
Das es andere sinnvolle Gründe für Objekte geben kann und gibt - das steht natürlich außer Frage. )

[Luckie]

Warum sind jetzt GOTOs eine Todsünde? Sinnvoll eigesetzt können sie durchaus sinnvoll sein. Ein exit oder ein break ist ja im Endeffekt auch nichts anderes.

[Robert_G]

Zitat:

Zitat von Luckie

Warum sind jetzt GOTOs eine Todsünde? Sinnvoll eigesetzt können sie durchaus sinnvoll sein. Ein exit oder ein break ist ja im Endeffekt auch nichts anderes.

Exakt, sinnvolle GOTOs können Code lesbarer machen. Ist äußerst selten, aber auch Luckie wird ab & zu GOTOs verwenden. Genau wie ich es auch machen würde. Aber halt nur innerhalb einer Methode, und dort nur um nicht 1.000 Zeilen AQbruchsbedingeungen in eine Schleife zu knallen.
break ist nunmal auch nur ein implizites GOTO, es springt an die erste Zeile nach der Schleife. ;)

[Delphi_Fanatic]

Zitat:

Warum sind jetzt GOTOs eine Todsünde? Sinnvoll eigesetzt können sie durchaus sinnvoll sein

Das überrascht mich jetzt, Luckie. :gruebel:

Von jemandem, der einerseits die Dinge so "eng" zu sehen scheint (globale Variablen vs. Objekte) hätte ich
jetzt so eine Einstellung bei Goto's nicht erwartet.
Tja, so hat halt jeder seine Meinung ... :???: Ich meine mich erinnern zu können, dass wir über Goto's in
der DP schon mal diskutiert hätten.

[Luckie]

Ich habe mich auch nicht strikt gegen globale Variablen ausgesprochen. Und in der letzten Diskussion über GOTOs sind wir auch zu dem Schluss gekommen, dass sie sinnvoll eingesetzt eine Daseinsberechtigung haben.

[SubData]

Zitat:

Zitat von Robert_G

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.

Muss ich nicht...
Die beiden Variablen werden nur einmal eingelesen und bleiben so erhalten... im ganzen Projekt...
Sie speichern nur einen Pfadnamen der sich zur kompletten Laufzeit NIEMALS ändert.
Dieser Pfadname wird auch nicht wieder zurück in irgend ne Datei geschrieben oder sonstwas...

Ich würds ja mit ner Konstante machen, aber der Pfad ist auf jedem Rechner evtl. anders :mrgreen:

[Delphi_Fanatic]

Zitat:

Und in der letzten Diskussion über GOTOs sind wir auch zu dem Schluss gekommen, dass sie sinnvoll eingesetzt eine Daseinsberechtigung haben.

Du meinst wohl, DU bist zu diesem Schluss gekommen ... ? :zwinker:

Mal eine ganz andere Frage an die "Fraktion" der Gegener von globalen Variablen :
Was ist denn mit den haus-eigenen globalen Variablen von Delphi selbst ?

Nehmt einfach mal "DateSeparator" !

Berechtigt, oder nicht berechtigt ? :roll:

[alcaeus]

Zitat:

Zitat von Delphi_Fanatic

Was ist denn mit den haus-eigenen globalen Variablen von Delphi selbst ?

Nehmt einfach mal "DateSeparator" !

Berechtigt, oder nicht berechtigt ? :roll:

IMO: Nicht berechtigt. Warum? Weil sowas in eine Date-Klasse, oder vielleicht ein SystemProperties gehoert. Zusammen mit DecimalSeparator, PathDelimiter etc. wuerde das eine schoene Sammlung von Optionen geben ;)

Greetz
alcaeus

[Alfons_G]

Man kann zusammenfassend vielleicht sagen, dass es zahlreiche Fälle gibt, wo globale Variablen keinen Schaden anrichten (Disziplin vorausgesetzt), wo man sie aber dennoch durch OOP-Konstrukte ersetzen kann. Ob man sogar die Formularvariablen verbannt, ist vermutlich eine Glaubensfrage. Solange man (vernünftigerweise) in den Formular-Units keine Business-Logik unterbringt, ist das m.E. ohne Auswirkungen auf die Fehleranfälligkeit.
Deshalb sollte man als Ersatz für globale Variablen auch nicht unbedingt Felder im Hauptformular verwenden. Besser ist da eine separate Klasse (oder mehrere logisch aufgeteilte Klassen) mit Business-Regeln, Standardwerten usw. Diese Klasse kann man dann beim Anwendungsstart initialisieren. Damit erleichtert man sich auch die Wiederverwendung, falls man dieselben Werte in einer anderen Anwendung wieder benötigen sollte.

Mit der Begründung "ist ja nur ein kleines Tool" wäre ich vorsichtig ;). Ich habe schon erlebt, dass ein 150-Zeilen-Hilfsprogramm zum Durchführen eines Datenabgleichs plötzlich innerhalb von 18 Monaten zu einer spezialisierten Data-Mining-Anwendung mit einigen Tausend Programmzeilen mutiert ist. Da ist man dann heilfroh, wenn man von Anfang an das Programm sorgfältig aufgebaut hat.
Nur hat man leider oft in der Praxis mit Alt-Quellcode zu tun, bei dem man froh ist, wenn er überhaupt irgendwie strukturiert wurde. Entweder ist da von OOP keine Spur, oder ein Genie hat alle Felder und Methoden einer Klasse als public deklariert und somit auf fast alle Vorteile der Objektorientierung verzichtet.
Für sowas schreibe ich nach Möglichkeit eine Schnittstelle (als Klasse), welche diese Units einbindet und alle Aufrufe kapselt. Dann kann ich den Alt-Code als Black Box behandeln.

Wir erstellen vorrangig Web-Anwendungen, wo man immer davon ausgehen muß, dass von jeder Ressource mehr als eine Instanz benötigt wird. Dazu arbeiten wir zum Teil mit vertraulichen Kundendaten, die auch zu Testzwecken nicht vom Original-Server gezogen werden dürfen und die sich aufgrund ihrer Komplexität auch nicht mit vertretbarem Aufwand simulieren lassen. Da ist es erforderlich, dass ein Tel der Tests dann in der Produktiv-Umgebung vorgenommen wird. Das geht natürlich nur, wenn man vorher bei kritischen Programmteilen genau weiß, wie sie sich verhalten werden. Deshalb ist es bei uns lebenswichtig, dass der Quelltext erstens sauber lesbar ist und zweitens so strukturiert, dass man ohne Probleme Unit-Tests durchführen kann.

Auch wenn öfters mal die Zeit nicht ausreicht, die Sourcen so zu kommentieren, wie ich es gerne hätte - meine Programme sind jedenfalls auch noch nach mehreren Jahren für alle beteiligten Kollegen nachvollziehbar :).

:coder:

[roderich]

Es ist mir echt schleierhaft, wie man dermaßen viel Zeit mit dieser Diskussion verbringen kann. :?

Geht es beim Software-Entwickeln darum, ein gerade "modernes" Konzept zu befriedigen ??
Oder darum, heute und morgen damit sein Geld zu verdienen, sprich effektiv und transparent zu entwickeln ??

Ich meine doch letzteres. Und diese Ziele kann man mit Konzepten aus den 70er Jahren des letzten Jahrtausends ebenso erreichen wie mit denen aus den 0er Jahren des aktuellen Jahrtausends. Wer etwas anderes behauptet, verkauft Leute wie Wirth für dumm. Ich frage mich, was manche Beiträger zu dieser Diskussion eigentlich beruflich (??) machen, ob sie überhaupt schon mal ein Produkt oder Projekt in Händen hatten, welches 20 Menschen über 10 Jahre ernährt hat und dies auch weiterhin tun soll. Unsere Kunden fragen mich nicht, ob wir XML, public properties, GOTO's oder globale Variablen verwenden. Sie wollen ein stabiles und mächtiges System.

In zehn Jahren wird keiner mehr von denen, die heute ausschließlich darauf schwören, OOP programmieren (dann gibt es nach .NET eh das noch neuere hyperintelligentschnickschnack.NET von Microsoft, was noch viiiiel besser ist). Leider wieder nur für Spielkinder geeignet, die Zeit zum verplempern haben.

Wer nicht das einsetzt, was bestmöglich den Zweck erfüllt, landet im Arbeitsamt.


Roderich