Lose Funktionen oder als Funktion in Klasse

**norwegen60**

Ich habe jahrelang so eine Klasse wie oben - aber nur mit procedure udn function - ohne Create und Free benutzt. Ohne Probleme.

Natürlich, und das ist ja auch nicht falsch. Wir zeigen hier lediglich andere Wege auf.

War auch nicht als Kritik gemeint
Es ging mir eher drum, zu erfahren, warum manche die globale Deklaration so verdammen. Ich weiß aber auch, dass man damit sehr unsauberen Code erzeugen kann.
Bei der Verwendung ohne Create hätte ich gedacht, dass es falsch ist und ich mich irgendwann mit einer neueren Delphi-Version gewundert hätte, warum der Code nicht mehr läuft

**himitsu**

"ohne Create" ... erstmal muß man dann eine Variable benutzen,
während man bei Class-Proicedure direkt den Typ nehmen kann.

Und so lange du auf nichts von der Klassen-Instanz zugreifst (z.B. Felder/Variablen), also das Self nie benutzt wird, dann gibt es auch keine Fehler, egal ob die Variable NIL oder sonstwie uninitialisiert (zufällig) ist.

Vorteil von Record statt Class ... man muß sich keine Gedanken um das Create machen, und vor allem auch nicht um das Free/Destroy.

Vorteil von Class-Constructor gegenüber Initialization, also für gesharetem Code (wäre schön, wenn es Emba mal nutzen würde),
dass bei Nichtbenutzung der Klasse sie auch garnicht erst einkompiliert gelinkt wird.

Steht der Create-Code in der Initialization, dann wird dadurch immer die Klasse "benutzt", auch wenn sie niemand nutzt.

**Uwe Raabe**

Am Ende sind solche class var bzw. class function (insbesondere wenn auch noch static) auch nichts anderes als globale Variablen bzw. Methoden. Es ändert sich lediglich die Syntax des Zugriffs.

Die Namensgebung wird auch etwas einfacher (obwohl die ja nie einfach ist), da man mit dem Klassennamen als Präfix eine gewisse Kapselung erhält, die bei echten globalen Variablen und Methoden ja nur über die Namensgebung erreicht werden kann. Wer hat nicht schon darüber geflucht, dass mit dem Einfügen einer Unit in die uses-Anweisung plötzlich eine gleichnamige Variable oder Methode im Scope weiter vorne steht und bestenfalls vom Compiler bemängelt wird. Die Lösung des Voranstellen des Unitnamens wird mit dem class/record Ansatz in der Regel überflüssig.

Nebenbei: Ist das nicht lästig, wenn man solche mit Unitnamen qualifizierte Zugriffe im Code hat und die Unit dann plötzlich nicht mehr Sysutils oder Windows, sondern System.Sysutils oder Winapi.Windows heißt. Da helfen die Unit-Scope-Names nämlich auch nicht.

**Blup**

Mir scheint wichtiger wie man auf solche globalen Resourcen zugreift.

Ich schotte den Anwendungsfall durch ein Provider von der Anwendungsumgebung ab.
Das kann eine abstrakte Klasse sein oder ein Interface, das den Zugriff kapselt.
Darüber werden alle vom Anwendungsfall benötigten globalen Funktionen, Methoden, Interfaces und Variablen bereitgestellt.

In der Anwendung werden die Zugriffe einfach nur durchgereicht.
Im Testfall kann eine ganz konkrete Umgebung simuliert werden (Mock).

Der Überblick über die Abhängigkeiten erleichtert auch die Aufwandschätzung und Realisierung von Erweiterungen oder
Migration eines Anwendungsfalls (z.B. Kommandozeile, Dienstprogramm, Webservice usw.).

**freimatz**

Zitat von norwegen60:

Es ging mir eher drum, zu erfahren, warum manche die globale Deklaration so verdammen. Ich weiß aber auch, dass man damit sehr unsauberen Code erzeugen kann.

Für Variablemen meine ich: Nicht kann, es ist schlechter Code.

Zum Warum gibt es im Netz vieles zu finden z.B.:

https://www.c-plusplus.net/forum/top...en-schlecht/39
In der Regel reicht eine einzigste eigene globale Variable für eine grössere Delphi-Anwendung.

**QuickAndDirty**

Ich habe hier ein Programm , das seit 1995 gewachsen ist.
Es ist voller globaler Variablen und nutzt intensiv komponenten (Datenbank Komponenten, Timer)die auf Formularen liegen...
Es gibt eine aus sicht des Users GUI freie version von dem Programm das als Webservice läuft.
Leider kann es immer nur eine anforderung nach der anderen bearbeiten...denn man kann ja Units mit ihren globalen variablen nicht für jeden Threadcontext neu instanzieren.
Hätten wir alles in Singletons abgespeichert hätte man die leicht zentral erweitern können dass es jeweils eine Instanz pro thread gibt.
In sofern sind Globale Variablen vielleicht langfristig gesehen nicht sehr flexible.

**himitsu**

Es gibt dann noch die Lösung von SubProzessen,
also wenn man es innerhalb des Programms nicht trennen kann, dann wird im Hintergrund z.B. je Connection eine neue Instanz gestartet und ihr die Aufgabe zugeteilt.

**Elvis**

Zitat von QuickAndDirty:

Hätten wir alles in Singletons abgespeichert hätte man die leicht zentral erweitern können dass es jeweils eine Instanz pro thread gibt.

Singletons sind nur hauchdünn marginal besser als globale variablen.
Vor allem wenn sie die shared instance der anderen Singletons nutzen.

**dummzeuch**

Zitat von Elvis:

Zitat von QuickAndDirty:

Hätten wir alles in Singletons abgespeichert hätte man die leicht zentral erweitern können dass es jeweils eine Instanz pro thread gibt.

Singletons sind nur hauchdünn marginal besser als globale variablen.
Vor allem wenn sie die shared instance der anderen Singletons nutzen.

Exakt: Singleton ist eigentlich eher ein Antipattern.

**Elvis**

Ist sicherlich absolut ok für services, die stateless arbeiten und/oder immutable options objekte.

Also Dinge, die sich nicht zur Laufzeit ändern können, können als Singleton oder Default instance angeboten werden.
Vor allem wenn man bedenken über sinnlos häufiges malloc hat. (in Delphi wohl weniger problematisch dank deterministischem manuellen Speichermanagement)

Aber: es ist viel sinnvoller sowas als Parameter an eine Methode oder einen ctor zu geben (readonly field/property).
Dann kann man am Ende entscheiden was man wie reinwirft. Denn Singletons lassen sich fast unmöglich für Tests mocken.