Lose Funktionen oder als Funktion in Klasse

**Rollo62**

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.

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

**Uwe Raabe**

Ein Singleton ist ja erstmal nur eine zentrale Instanz, die nur einmal im Programm existiert. Das bedeutet aber nicht, dass diese Instanz immer die gleiche Implementierung haben muss.

Zitat von https://de.wikipedia.org/wiki/Singleton_(Entwurfsmuster):

Das Singleton findet Verwendung, wenn

nur ein Objekt zu einer Klasse existieren darf und ein einfacher Zugriff auf dieses Objekt benötigt wird oder
das einzige Objekt durch Unterklassenbildung spezialisiert werden soll.

Für Unittests kann man ja auch einen Mock als Singleton verwenden. Auch ein

Null-Object als Default-Implementation ist zulässig, wenn keine andere Implementierung benötigt wird.

Wenn das nicht ginge, könnte man die Singleton-Klassen ja gleich als sealed deklarieren.

**Elvis**

ein klassisches singleton sorgt dafür dass es nur eine Instanz geben kann.
entweder weil die Klasse einen private ctor hat, oder du verschiedene static readonly References hast.

Du kannst sowas nur sinnvoll mocken, wenn du sie nicht als singletons verwendest, sondern als ctor oder Methoden-Parameter.

Aber wenn du sie so verwendest hast du auch fast keine Nachteile des Singletons mehr.

Sorry für mein c#, keine mich mit modernem Delphi nicht gut genug aus…
Das ist, als ob du einen IEqualityComparer<string> als Parameter nimmst, und den in deinem IOC container statisch als „singleton“ registrierst.

Allerdings kannst du jederzeit das interface mocken um edge cases in einem test zu entdecken.
Dein code geht ja nicht zu der einen statischen Stelle, um sich StringComparer.Ordinal zu holen.
Das gibst du ihm ja nur indirekt per DI oder Parameter.

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

**Uwe Raabe**

Zitat von freimatz:

Und das halte ich für einen Denkfehler. Also die Meinung dass es nur eines geben kann. Man hat sich da schon oft geirrt.

Das mag vielleicht sein, aber die Entscheidung obliegt dem Entwickler der diese im Kontext seiner Anwendung macht. Eine pauschale Verurteilung von Singletons ist ebenso fehlgeleitet wie eine falsche Verwendung eines solchen. Natürlich gibt es Fälle, in denen ein Singleton die falsche Wahl ist, aber es gibt genügend Fälle wo das nicht gilt. Das kann man eben nicht pauschal beurteilen sondern sollte das immer vom konkreten Anwendungsfall oder Kontext abhängig machen. Und natürlich kann sich dieser Kontext im Lebenslauf einer Anwendung ändern, aber das ist doch des Entwicklers täglich Brot.

**himitsu**

Wenn man das Singleton nicht hart in diese Klasse einbaut, sondern es auch ermöglicht dennoch weitere Instanzen davon zu erstellen (die globale "Variable" als Singleton, aber dennoch jetzt/zukünftig weitere Instanzen, z.B. für gewisse Threads),
dann hat man dennoch alle Möglichkeiten.

z.B. eine generische Implementation für die Variable, nicht im Objekt selber, oder zumindestens in einem gemeinsamen Vorfahren davon.
Dann lässt sich in Zukunft das z.B. so abändern, dass jeder Thread eine eigene Instanz bekommt (ThreadPool), welche vielleicht ihre Standardwerte von der globalen Hauptthread-Instanz oder einer anderen "Default"-Instanz erben/kopieren.

**Uwe Raabe**

Ich verwende dafür gerne eine kleine generische Hilfsklasse, mit der ich (nahezu) jede Klasse bei Bedarf zu einem Singleton machen kann, ohne die Verwendung auf diesen Fall zu beschränken:

zusammenfalten · markieren

Delphi-Quellcode:

			unit Common.Singleton;

interface

type

  TSingleton<T:class, constructor> = class

  strict private

  class var

    FInstance: T;

    class destructor DestroyClass;

  private

    class function GetInstance: T; static;

  public

    class property Instance: T read GetInstance;

  end;

implementation

class destructor TSingleton<T>.DestroyClass;

begin

  FInstance.Free;

end;

class function TSingleton<T>.GetInstance: T;

begin

  if FInstance = nil then

    FInstance := T.Create;

  result := FInstance;

end;

end.

Der Zugriff erfolgt dann über entsprechende Methoden wie z.B. diese:

markieren

Delphi-Quellcode:

			function TranslationManager: TTranslationManager;

begin

  result := TSingleton<TTranslationManager>.Instance;

end;

oder je nach Geschmack auch als Klassenmethode:

markieren

Delphi-Quellcode:

			class function TTranslationManager.Singleton: TTranslationManager;

begin

  Result := TSingleton<TTranslationManager>.Instance;

end;

Letzteres verdeutlicht die Singleton-Eigenschaft schon im Namen, aber das ist vielleicht nicht immer erwünscht.

**jaenicke**

So eine Funktionalität mit automatischer Freigabe und einem Singleton als Klasse könnte ich in AppCentral natürlich auch einmal einbauen.

Bisher hatte ich das nur für Interfaces vorgesehen und würde es selbst auch nicht anders nutzen, aber wenn da Interesse besteht, wäre es kein Problem.