Warum ist ein Singleton kein Best Practise?

[kossy]

Hallo !

Ich hab mal gehört, dass die Verwendung eines Singleton angeblich kein Best Practise sein soll und es im Prinzip nur eine große gloable Variable darstellen sollen.

Ist das tatsächlich so? Oder nur ein falsches Gerücht? Und wenn dem so ist, was wäre dann eine gute Alternative dazu?

Grüße
Kossy

 

[Wildcard]

Singletons sind großer Mist. Aus verschiedenen Gründen:
-Erschweren das Unit Testen massiv
-Verletzen das Single Responsibility Principle weil die Klasse sich sowohl um ihre eigentliche Aufgabe, als auch um die eigene Objekterzeugung kümmert
-Führen einen globalen Zustand in die Anwendung ein
-Tight Coupling, weil man Klienten zwingt sich an eine Implementierung anstatt an ein Interface zu binden
-Kein anderes der ürsprünglichen GoF Patters wurde derartig oft missbraucht
-...

Gibt jede Menge Threads hier und zahllose Artikel im Netz.
Eine übliche Alternative für Singletons ist Dependency Injection.
Das nur eine Instanz einer Klasse erzeugt wird, ist eine Art wie eine Klasse benutzt wird (und das lässt sich bei Dependency Injection auch einfach umsetzen), keine direkte Eigenschaft der Klasse wie im ursprünglichen Singleton Muster.

 

[musiKk]

-Kein anderes der ürsprünglichen GoF Patters wurde derartig oft missbraucht

In dem Zusammenhang finde ich es ganz interessant, dass dieses auch das einzige Pattern ist, welches Gamma in einer Neuauflage weglassen würde.

When discussing which patterns to drop, we found that we still love them all. (Not really—I'm in favor of dropping Singleton. Its use is almost always a design smell.)

 

[Landei]

Dependency Injection ist der beste Ersatz, wie Wildcard schon schrub, aber dafür braucht man eine Bibliothek oder ein Framework (Guice, Spring...). Wenn man das in kleineren Projekten nicht will, sollte man dem Singleton ein Interface verpassen und eine Factory dazwischenschalten:

interface Foo {
   public void bar();
}

class FooSingleton implements Foo {
   public void bar(){ System.out.println("Hi, I'm single!"); }
}

class FooFactory {
   private static Foo INSTANCE = new FooSingleton(); 

   public static Foo getInstance(){ return INSTANCE; }
}

Wenn jetzt alle Clients ihr Foo nur über die Factory holen, kann man nachträglich leicht die Implementierung ändern. Die Factory könnte z.B. in einer Properties-Datei nachschauen, ob es das "echte" FooSingleton zurückgibt oder eine für Tests geeignete Variante (z.B. ohne Datenbankverbindungen und dafür mit ein paar Fake-Daten). Unter Umständen ist auch eine abstrakte Factory hilfreich.

Wenig bekannt, aber ebenfalls praktisch ist der SPI-Mechanismus von Java, der eigentlich zum einfachen Laden von Plugins u.s.w. da ist. Dort kann ein Jar Implementierungen für ein bestimmtes Interface (mittels einer Text-Datei in META-INF) "bekannt machen", und Client Code kann sich diese Implementierungen dann zurückgeben lassen. Auch damit lässt sich (am besten innerhalb einer Factory) die enge Kopplung an eine bestimmte Implementierung vermeiden.