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

[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: