Warum einen Singleton anstelle statischer Methoden verwenden?

Ich habe nie gute Antworten auf diese einfachen Fragen zu Hilfs- / Dienstprogrammklassen gefunden:

Warum sollte ich einen Singleton (zustandslos) erstellen, anstatt statische Methoden zu verwenden?

Warum wird eine Objektinstanz benötigt, wenn ein Objekt keinen Status hat?

Oft werden Singletons verwendet, um einer Anwendung einen globalen Status hinzuzufügen. (Um ehrlich zu sein, meistens als wirklich notwendig, aber das ist ein Thema für ein anderes Mal.)

Es gibt jedoch einige Eckfälle, in denen sogar ein zustandsloser Singleton nützlich sein kann:

• Sie erwarten, es in absehbarer Zeit mit dem Staat zu erweitern.
• Sie benötigen aus einem bestimmten technischen Grund eine Objektinstanz . Beispiel: Synchronisationsobjekte für die C # - oder die Java- Anweisung.
  locksynchronized
• Sie benötigen eine Vererbung, dh Sie möchten Ihren Singleton problemlos durch einen anderen ersetzen können, indem Sie dieselbe Schnittstelle, aber eine andere Implementierung verwenden.
  Beispiel: Die Toolkit.getDefaultToolkit()Methode in Java gibt einen Singleton zurück, dessen genauer Typ systemabhängig ist.
• Sie möchten eine Referenzgleichheit für einen Sentinel-Wert .
  Beispiel: DBNull.Valuein C #.

Ich konnte einen Fall für einen zustandslosen Singleton anstelle einer statischen Methodenklasse sehen, nämlich für Dependency Injection .

Wenn Sie über eine Hilfsklasse von Dienstprogrammfunktionen verfügen, die Sie direkt verwenden, wird eine versteckte Abhängigkeit erstellt. Sie haben keine Kontrolle darüber, wer es wo verwenden kann. Wenn Sie dieselbe Hilfsklasse über eine zustandslose Singleton-Instanz einfügen, können Sie steuern, wo und wie sie verwendet wird, und sie bei Bedarf ersetzen / verspotten / usw.

Wenn Sie es zu einer Singleton-Instanz machen, stellen Sie einfach sicher, dass Sie nicht mehr Objekte des Typs als erforderlich zuweisen (da Sie immer nur eines benötigen).

Eigentlich habe ich eine andere Antwort gefunden, die hier nicht erwähnt wird: Statische Methoden sind schwerer zu testen.

Es scheint, dass die meisten Test-Frameworks hervorragend zum Verspotten von Instanzmethoden geeignet sind, aber viele von ihnen behandeln das Verspotten statischer Methoden nicht auf anständige Weise.

In den meisten Programmiersprachen entziehen sich Klassen einem Großteil des Typsystems. Während eine Klasse mit ihren statischen Methoden und Variablen ein Objekt ist, kann sie sehr oft keine Schnittstelle implementieren oder andere Klassen erweitern. Aus diesem Grund kann es nicht polymorph verwendet werden, da es nicht der Subtyp eines anderen Typs sein kann. Zum Beispiel, wenn Sie eine Schnittstelle IFooable, die von mehreren Verfahren Signaturen anderer Klassen erforderlich ist, das Klassenobjekt StaticFookann nicht anstelle verwendet werden , IFooablewährend, FooSingleton.getInstance()kann (unter der Annahme, FooSingletonGeräten IFooable).

Bitte beachten Sie, dass, wie ich Heinzis Antwort kommentierte, ein Singleton ein Muster zur Steuerung der Instanziierung ist. Sie ersetzt new Class()mit Class.getInstance(), was den Autor gibt Classmehr Kontrolle über Instanzen, die er die Schaffung von unnötigen Instanzen zu verhindern , verwenden kann. Der Singleton ist nur ein ganz besonderer Fall des Fabrikmusters und sollte als solcher behandelt werden. Die allgemeine Verwendung macht es eher zum Sonderfall globaler Register, was oftmals schlecht ist, da globale Register nicht einfach so oder so verwendet werden sollten.

Wenn Sie globale Hilfsfunktionen bereitstellen möchten, funktionieren statische Methoden einwandfrei. Die Klasse fungiert nicht als Klasse, sondern nur als Namespace. Ich schlage vor, Sie bewahren einen hohen Zusammenhalt, oder Sie könnten mit seltsamsten Kopplungsproblemen enden.

greetz
back2dos

Es gibt einen Kompromiss zwischen der Verwendung welcher. Singletons können einen Status haben oder nicht und sie beziehen sich auf Objekte. Wenn sie nicht den Status beibehalten und nur für den globalen Zugriff verwendet werden, ist statisch besser, da diese Methoden schneller sind. Wenn Sie jedoch Objekte und OOP-Konzepte (Inheritance Polymorphism) verwenden möchten, ist Singleton besser.

Betrachten Sie ein Beispiel: java.lang.Runtime ist eine Singleton-Klasse in Java. Diese Klasse ermöglicht unterschiedliche Implementierungen für jede JVM. Die Implementierung ist pro JVM einzeln. Wenn diese Klasse statisch gewesen wäre, können wir keine unterschiedlichen Implementierungen basierend auf JVM übergeben.

Ich fand diesen Link wirklich hilfreich: http://javarevisited.blogspot.com/2013/03/difference-between-singleton-pattern-vs-static-class-java.html ?

Ich hoffe es hilft!!

Für mich "Want Object State Singleton verwenden, Want Function statische Methode verwenden"

Es kommt darauf an, was Sie wollen. Wann immer Sie den Objektzustand wollen (zB Polymorphismus wie Nullzustand stattnull oder Standardstatus), ist Singleton die geeignete Wahl für Sie, während die statische Methode verwendet wird, wenn Sie eine Funktion benötigen (Eingaben empfangen und dann eine Ausgabe zurückgeben).

Ich empfehle für den Singleton-Fall, dass er nach der Instanziierung immer den gleichen Status haben sollte. Es sollte weder klonbar sein noch einen Wert erhalten, in den es gesetzt werden soll (außer statische Konfiguration aus der Datei, z. B. Eigenschaftendatei in Java).

PS Die Leistung zwischen diesen beiden ist in Millisekunden unterschiedlich. Konzentrieren Sie sich also zuerst auf die Architektur .

Singleton ist nicht staatenlos, es hält den globalen Zustand.

Einige Gründe, die ich mir vorstellen kann, Singleton zu verwenden, sind:

• Um Speicherlecks zu vermeiden
• Bereitstellen des gleichen Status für alle Module in einer Anwendung, z. B. Datenbankverbindung