Jetzt konnte ich' doch nicht lassen...
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 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 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?
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
)
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.