Lose Funktionen oder als Funktion in Klasse

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

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

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:

Delphi-Quellcode:

function TranslationManager: TTranslationManager;
begin
  result := TSingleton<TTranslationManager>.Instance;
end;

oder je nach Geschmack auch als Klassenmethode:

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.

[Rollo62]

Zitat von freimatz:

- 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

Richtig, und wenn es sich mal ändert, dann muss man das halt mit ändern.
Die Änderung geht aber geordnet innerhalb einer Klasse aus meiner Sicht etwas einfacher als bei losen, verstreuten Funktionen.

So gibt es viele "Einheiten" in der Software, welche man über Jahrzehnte nicht anfassen muss.

So eben auch "Device-Orientation", was dann verschiedene Settings unter Portrait und Landscape kapselt.
Das ist z.B. bei mir ein TOrientation-Singleton, für meine Single-Display Projekte, für Tablets und Phones.
Jetzt kommt neuerdings noch "FlipDisplay" und ein rundes "Watch-Display" dazu, das muss halt bei Bedarf erweitert werden,
bleibt aber meiner Meinung immer noch schön unter einem Orientation-Singleton.

Du hast Recht, gibt es auf einmal 5 Device-Displays oder ein ansteckbares USB-Display, dann muss das entsprechend erweitert werden.

Dann verwaltet das Singleton halt auch dynamisch zu mountende USB-Display, es ist aber immer noch ein TDisplays Singleton für mich.
Kann man anders machen, muss man aber nicht.
Ich weiß jedenfalls, dass dieses Singleton wieder Jahrzehnte Bestand haben wird.

Der Vorteil, den ich speziell in diesem Fall sehe ist, dass die Domain "Displays" ein Singleton bleibt, egal wie viele und welche Displays ich noch dazu baue.
Aus meiner Sicht hängen alle Displays eben logisch zusammen und deshalb macht EIN Singleton für mich da immer noch Sinn.
Ein zentraler Verwalter für alle Displays, der könnte verschiedene Funktionen übernehmen.
Das kann er nicht, wenn alle Displays nur separat gesteuert werden.
Zumal die Displays in einer Session nicht tausendmal erzeugt und zerstört werden müssen.

Ok, ist aber meine Philosophie zu dem Thema, generell versuche ich auch Singletons zu vermeiden.
Insbesondere aber bei Hardware-nahen System setze ich das aus o.g. Gründen gerne ein.

[freimatz]

Zitat von Rollo62:

Ok, ist aber meine Philosophie zu dem Thema, generell versuche ich auch Singletons zu vermeiden.
Insbesondere aber bei Hardware-nahen System setze ich das aus o.g. Gründen gerne ein.

Wenn man das so wie Du gut durchdacht hat finde ich das auch ok. Meine Intention war, dass man sich überhaupt mal darüber Gedanken macht bevor man das verwendet.