Lose Funktionen oder als Funktion in Klasse

[norwegen60]

Zitat von Uwe Raabe:

Zitat von 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

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

[jaenicke]

Zitat von Elvis:

Denn Singletons lassen sich fast unmöglich für Tests mocken.

Kommt drauf an wie man sie umsetzt.

Ich arbeite dazu hiermit:
https://www.delphipraxis.net/213199-...ng-dlls-c.html

Das hat den Vorteil, dass man das Singleton global registriert, es aber per Interface entkoppelt ist. Deshalb kann man es wie ein Singleton nutzen, aber problemlos mocken.

[Rollo62]

Zitat von dummzeuch:

Exakt: Singleton ist eigentlich eher ein Antipattern.

Mag sein, trotzdem nehme ich Singletons gerne für Objekte von denen es aus logischen, physischen oder Hardwaregründen nur eines geben kann, z.B.
ein TApp Objekt (Basic App Daten), ein TOrientation Objekt (Portrait/Landscape), ein TDisplays Objekt (Daten zu Monitoren), ...

Die baue ich dann möglichst so, dass ich problemlos überall nutzen kann, um die drunter-liegenden, realen Dinge zu kapseln.
Das ist auch oft nur ein einmaliges Ermittlen von Basis-Daten, was dann oft in der App nur abgefragt wird.
Da macht ein Singleton für mich schon sehr viel Sinn, um die ansonsten ungeschützen Zugriffe besser zu kapseln und zu entkoppeln.

[freimatz]

Zitat von Rollo62:

Zitat von dummzeuch:

Exakt: Singleton ist eigentlich eher ein Antipattern.

Mag sein, trotzdem nehme ich Singletons gerne für Objekte von denen es aus logischen, physischen oder Hardwaregründen nur eines geben kann, z.B.
ein TApp Objekt (Basic App Daten), ein TOrientation Objekt (Portrait/Landscape), ein TDisplays Objekt (Daten zu Monitoren), ...

Und das halte ich für einen Denkfehler. Also die Meinung dass es nur eines geben kann. Man hat sich da schon oft geirrt.
- Die Software ist für eine Maschine. Schon, aber nun hat die Maschine plötzlich meherer Einheite die man steuern muss.
- Orientation? Nun will man die erste Seite quer die anderen längs
- Daten zu Monitoren - nun hat man sechs, will aber immer drei als ein Set behandeln. (Hat mich schon oft gestört dass Remote Desktop nur einer oder alle Montore kann)
Meistens ist es ja ok und allermeist bleibt es dann auch bei einem einzelnen Objekt. Flexibler ist man wenn man es nicht als Singleton implementiert.
Wir haben in der Firma auch Objekt, aber dort wird es konfiguriert ob der Dependency Container eine Klasse als Singleton erzeugt oder nicht.
Und damit kann man die eben auch Mocken.