Singleton-Realisierung

[Dark_Rider]

Hi!
Ich habe eine Frage zu der Realisierung von Singleton-Klassen. Wenn man jetzt ein Projekt hat, in dem mehrere Klassen Singleton sein sollen, dann wäre es doch irgendwie sinnvoll eine eigene Klasse Singleton zu erstellen, von der dann jede der Klassen erben soll. Der Nachteil ist aber der, dass diese nicht mit statischen Methoden arbeiten kann, weil ja jede Klasse die Methode braucht.
Die spontane Idee wäre es die entsprechenden Klassen direkt selber zu Singleton zu machen, also in jeder Klasse eine statische Methode einfügen, wie GetTheInstance() usw.
Meine Frage ist jetzt: Sollte man das immer so machen, dass man entsprechende Klassen direkt als Singleton macht, auch wenn man mehrere davon haben möchte? Ist es möglich irgendwie eine Klasse Singleton anzulegen, von der jede Klasse erbt?
Mich würde vor allem interessieren, wie man es in Firmen macht.

Danke im Voraus auf Antworten!

 

[engelmarkus]

Also ich würde keine Singleton-Klasse erstellen, von der ich andere ableite. Wenn du willst, könntest du das aber in etwa so machen, kommt natürlich auf die Sprache an:

Public MustInherit Class Singleton(Of T As New)
    Public Shared Instance As T

    Shared Sub New()
        Instance = New T()
    End Sub

    Protected Sub New()
    End Sub
End Class

Public Class S1
    Inherits Singleton(Of S1)

    Sub Test()
    End Sub
End Class

Man erstellt eine abstrakte generische Klasse, von der man ableitet. Will man jetzt auf die Instanz zugreifen, geht das so:

S1.Instance.Test()
' oder
Singleton(Of S1).Instance.Test()

Aber ich muss ganz ehrlich sagen, ich sehe den Sinn darin nicht .

 

[Dark_Rider]

Danke für die Antwort!
Der Sinn wäre darin, dass man nicht in jeder Klasse immer wieder eine Methode schreiben muss wie getSingleton. Zwar ist es nur wenig Code, aber auf diese Weise kann man mehr Struktur in den Code einbauen.

 

[Wolfsbein]

... dass man nicht in jeder Klasse immer wieder eine Methode schreiben muss wie getSingleton....

Wenn du mit getSingleton getInstannce meinst, was hilft dir dann eine ererbte Methode? Instanzieren musst du trotzdem die korrekte Klasse, was zu Ueberschreiben eben dieser Methode fuehren wuerde.

 

[Dark_Rider]

Genau das ist eines der Probleme, weswegen das nicht funktioniert. Mich hätte es eben nur interessiert, ob man das vielleicht auch so lösen kann, aber dann werde ich das wohl überall selbst reincoden.

Danke euch!

 

[engelmarkus]

Wenn du eine generische Klasse erstellst, oder ein Template in C++, dann wird doch automatisch die korrekte Klasse instanziert?
So arbeitet doch auch mein Beispiel.

 

[tfa]

Man sollte es sich zweimal überlegen, ob man wirklich ein Singleton braucht. Singletons werden häufig falsch verwendet, schränken das Design unnötig ein, sind schwer zu testen. Manche bezeichnen sie sogar als Anti-Pattern.
Gleich mehrere Singletons (eine ganze Singleton-Hierarchie) anzulegen, stinkt gewaltig meiner Meinung nach.

 

[Oliver Gierke]

Man sollte es sich zweimal überlegen, ob man wirklich ein Singleton braucht. Singletons werden häufig falsch verwendet, schränken das Design unnötig ein, sind schwer zu testen. Manche bezeichnen sie sogar als Anti-Pattern.
Gleich mehrere Singletons (eine ganze Singleton-Hierarchie) anzulegen, stinkt gewaltig meiner Meinung nach.

Unterschreib ich komplett. Das GoF Buch hat dafür gesorgt, dass in vielen Köpfen die Eigenschaft, nur eine einzelne Instanz einer Klasse zu bekommen mit der Implementierung gleichgesetzt wurde. Gerade was die multithreading Eigenschaften von Singletons angeht sind die meisten Implementierungen kaputt.

IMHO ist die Singletoneigenschaft nichts, was die Klasse selbst zu managen hätte. Dadurch verletzt sie nämlich das Prinzip des Separation of Concerns, weil sie damit schon zwei Aufgaben hat (ihre eigentliche + die Singletoneigenschaft sicherzustellen). Im Idealfall überlässt man das Sicherstellen dieser Eigenschaft einem Container, oder - wenn es ne Nummer kleiner sein soll, einer Factory, die eben nur eine Instanz der Klasse erzeugt.

Für die Javawelt dürfte der (mir bis vor kurzem unbekannte) Ansatz Singletons über Enums zu implementieren recht interessant sein. Durch diesen Ansatz wird vor allem das Problem des Multithreadings komplett an die VM abgegeben. Zudem sieht der Code auch ganz hübsch aus:

public enum MySingletonImplementation implements MyInterface {
  
  INSTANCE;

  public void someMethod(String foo) {
 
  }
}

MyInterface instance = MySingletonImplementation.INSTANCE;

Die ganzen von tfa aufgezählten Nachteile gelten natürlich weiterhin.

Gruß
Ollie

 

[tfa]

Als (bessere) Alternative empfehle ich ein Dependency-Injection Framework, z.B. Spring. Hier kann man auch zentral Java-Objekte (Beans) erzeugen und verwalten lassen. Wenn man den Scope des Bean auf "singleton" stellt, wird sogar sichergestellt, dass nur ein Objekt des Beans angelegt wird. Dieses "Singleton" hat allerdings nichts dem Absolutheitsanspruch eines GOF-Singleton zu tun. Dessen Nachteile treten hier nicht auf.