Singleton - The Easy Way!

[suckerpunch]

Hallo Liebe Forengemeinde,

 

die Fortgeschrittenen unter uns kennen sicherlich das Singleton-Pattern, dies muss oft händisch für jede Klasse neu implementiert werden, was es gerade Anfängern schwer macht es immer umzusetzen.

 

Ich mach es kurz, diese Klasse soll es jeden erleichtern das Pattern umsetzen und allein durch das erweitern dieser Klasse ein Singleton zu haben

 

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace Util
{
/// <summary>
/// Lazy-loading singleton
/// </summary>
/// <typeparam name="T">The type to have the singleton instance of</typeparam>
[serializable]
public abstract class Singleton<T> where T : new()
{
	/// <summary>
	/// Private constructor to avoid external instantiation.
	/// </summary>
	/// <remarks>
	/// This is present to keep the compiler from providing a default public constructor
	/// </remarks>
	protected Singleton()
	{

	}

	/// <summary>
	/// Return an instance of
	/// </summary>
	public static T Instance
	{
		get { return SingletonHolder.instance; }
		set { SingletonHolder.instance = value; }
	}

	/// <summary>
	/// Sealed class to avoid any heritage from this helper class
	/// </summary>
	private sealed class SingletonHolder
	{
		internal static T instance = new T();

		/// <summary>
		/// Explicit static constructor to tell C# compiler not to mark type as beforefieldinit
		/// </summary>
		static SingletonHolder()
		{
		}
	}
}
}

 

Es ist Hauptsächlich für die typischen Klassen gedacht die nur einmal vorkommen sollen, NetworkService, DataLoader, verschiedene Engines

 

Benutzung wäre dann einfach

public class MySQL : Singleton<MySQL>
{
}

 

Und schon wäre die Klasse MySQL ein Singleton und kann nur einmal erzeugt werden.

 

Mit freundlichen Grüßen

 

suckerpunch

 

PS: Die Klasse stammt aus einem sehr sehr großen Projekt und ist eigentlich hinreichend erprobt.

[AgentCodeMonk]

Schöne Sache. Nur der Vollständigkeit halber: da fehlt das "using System;"

[suckerpunch]

Ist ja nur die Klasse ohne Namespace und Using Angaben, das ergänzt die IDE ja bereitwillig : )

[Schlumpf]

oder schreit jämmerlich und schmeißt uns fehler um die ohren

[suckerpunch]

Gut jetzt einfach mal die unbereinigte (Standard Using's) Klasse kopiert

[DW-Soul]

Sehr gut erklärt. :-)

[kayy]

Hmmh, ich muss mal kurz trollen - Sorry Also in einem kleinen Projekt nutze ich gerne Singletons und ignoriere die ganze Kritik von wegen Anti-Pattern und so (s. ^{[1][2][3][4][5][6]}). Aber in einem sehr, sehr großen Projekt würde ich es anders designen, weil es echte Probleme geben kann. Vor allem die Reihenfolge der Initialisierung - muss nicht aber - kann zu Fehlern führen, die nur schwer zu fixen sind. Mock-Objekt-Instanziierung für Test-Fälle u.ä. wird auch eher komplexer. Da tendiere ich in diesem Fall (großes Projekt) eher zu einer zentralen Klasse, die die Instanzen kreiert und verwaltet.

 

Ich würde auch für ein Singleton ungern den einen Schuss opfern, den man bei der Vererbung hat. Irgendwie kommt mir das nicht natürlich vor, dies als Is-A-relationship zu designen. Wenn ich z.B. von MonoBehaviour abgeleitete Objekte mit DontDestroyOnLoad habe, so sind diese meistens auch Singleton-artig unterwegs. In diesem Fall kann ich kein ": Singleton<MyClass>" angeben und somit habe ich doch 2 verschiedene Wege, mit Singletons zu arbeiten.

 

Aber: Man kann das so sehen und beim Software-Design gibt es kein Richtig und Falsch (manchmal ist da sogar das sogenannte Richtige falsch oder das vermeintlich Falsche richtig

[suckerpunch]

Man muss Singleton's natürlich auch dort anwenden wo sie Sinn machen wenn hinter der Klasse eine Vererbungsstruktur steht dann sollte man eh meistens die Finger davon lassen weil das zu ganz anderen Problemen führt. Das was du ansprichst Zentrale Klasse die Instanzen verwaltet und erzeugt ist doch eher das Factory-Pattern.

 

Würde mich bei Singleton's wirklich auf Engines, Loaders, DAOs beschränken

[DynamicHead]

Ich würde Singletons im Zusammenhang mit Unity eher auf der Mülleimer beschränken.. außer man lernt gerade programmieren. Dann sollte man das auch mal benutzen.

[AgentCodeMonk]

Ich würde Singletons im Zusammenhang mit Unity eher auf der Mülleimer beschränken

hä?

 

Ich sehe das wie suckerpunch ...wo sie Sinn machen - und ja das gibt´s auch immer wieder in Unity - machen sie eben Sinn

[Sascha]

Ich finde (naja, "Pseudo"-)Singeltons in Unity interessant, wenn man was im Update-Zyklus braucht, aber eben keinen Nutzen von mehreren Instanzen hat.

Ich finde den Code ganz cool, auch wenn ich nichts damit anfangen kann. Das nächste Mal, wenn ich eins brauche, schaue ich mal, ob ich was daraus mopsen und in ein MonoBehaviour und in Awake integrieren kann.