Develop Reference

Make a 'new' object/class global in C# [duplicate]

What is a Singleton and when should I use it?

A singleton is a class which only allows one instance of itself to be created - and gives simple, easy access to said instance. The singleton premise is a pattern across software development.
There is a C# implementation "Implementing the Singleton Pattern in C#" covering most of what you need to know - including some good advice regarding thread safety.
To be honest, It's very rare that you need to implement a singleton - in my opinion it should be one of those things you should be aware of, even if it's not used too often.

You asked for C#. Trivial example:
public class Singleton
{
private Singleton()
{
// Prevent outside instantiation
}
private static readonly Singleton _singleton = new Singleton();
public static Singleton GetSingleton()
{
return _singleton;
}
}

What it is: A class for which there is just one, persistent instance across the lifetime of an application. See Singleton Pattern.
When you should use it: As little as possible. Only when you are absolutely certain that you need it. I'm reluctant to say "never", but there is usually a better alternative, such as Dependency Injection or simply a static class.

another way to implement singleton in c#, i personally prefer this way because you can access the instance of the singeton class as a property instead of a method.
public class Singleton
{
private static Singleton instance;
private Singleton() { }
public static Singleton Instance
{
get
{
if (instance == null)
instance = new Singleton();
return instance;
}
}
//instance methods
}
but well, as far as i know both ways are considered 'right' so it's just a thing of personal flavor.

using System;
using System.Collections.Generic;
class MainApp
{
static void Main()
{
LoadBalancer oldbalancer = null;
for (int i = 0; i < 15; i++)
{
LoadBalancer balancerNew = LoadBalancer.GetLoadBalancer();
if (oldbalancer == balancerNew && oldbalancer != null)
{
Console.WriteLine("{0} SameInstance {1}", oldbalancer.Server, balancerNew.Server);
}
oldbalancer = balancerNew;
}
Console.ReadKey();
}
}
class LoadBalancer
{
private static LoadBalancer _instance;
private List<string> _servers = new List<string>();
private Random _random = new Random();
private static object syncLock = new object();
private LoadBalancer()
{
_servers.Add("ServerI");
_servers.Add("ServerII");
_servers.Add("ServerIII");
_servers.Add("ServerIV");
_servers.Add("ServerV");
}
public static LoadBalancer GetLoadBalancer()
{
if (_instance == null)
{
lock (syncLock)
{
if (_instance == null)
{
_instance = new LoadBalancer();
}
}
}
return _instance;
}
public string Server
{
get
{
int r = _random.Next(_servers.Count);
return _servers[r].ToString();
}
}
}
I took code from dofactory.com, nothing so fancy but I find this far good than examples with Foo and Bar additionally book from Judith Bishop on C# 3.0 Design Patterns has example about active application in mac dock.
If you look at code we are actually building new objects on for loop, so that creates new object but reuses instance as a result of which the oldbalancer and newbalancer has same instance, How? its due to static keyword used on function GetLoadBalancer(), despite of having different server value which is random list, static on GetLoadBalancer() belongs to the type itself rather than to a specific object.
Additionally there is double check locking here
if (_instance == null)
{
lock (syncLock)
{
if (_instance == null)
since from MSDN
The lock keyword ensures that one thread does not enter a critical section of code while another thread is in the critical section. If another thread tries to enter a locked code, it will wait, block, until the object is released.
so every-time mutual-exclusion lock is issued, even if it don't need to which is unnecessary so we have null check.
Hopefully it helps in clearing more.
And please comment if I my understanding is directing wrong ways.

A Singleton (and this isn't tied to C#, it's an OO design pattern) is when you want to allow only ONE instance of a class to be created throughout your application. Useages would typically include global resources, although I will say from personal experience, they're very often the source of great pain.

Whilst the there can only ever be one instance of a singleton, it is not the same as a static class. A static class can only contain static methods and can never be instantiated, whereas the instance of a singleton may be used in the same way as any other object.

It's a design pattern and it's not specific to c#. More about it all over the internet and SO, like on this wikipedia article.
In software engineering, the singleton
pattern is a design pattern that is
used to restrict instantiation of a
class to one object. This is useful
when exactly one object is needed to
coordinate actions across the system.
The concept is sometimes generalized
to systems that operate more
efficiently when only one object
exists, or that restrict the
instantiation to a certain number of
objects (say, five). Some consider it
an anti-pattern, judging that it is
overused, introduces unnecessary
limitations in situations where a sole
instance of a class is not actually
required, and introduces global state
into an application.
You should use it if you want a class that can only be instanciated once.

I use it for lookup data. Load once from DB.
public sealed class APILookup
{
private static readonly APILookup _instance = new APILookup();
private Dictionary<string, int> _lookup;
private APILookup()
{
try
{
_lookup = Utility.GetLookup();
}
catch { }
}
static APILookup()
{
}
public static APILookup Instance
{
get
{
return _instance;
}
}
public Dictionary<string, int> GetLookup()
{
return _lookup;
}
}

What is a singleton :
It is a class which only allows one instance of itself to be created, and usually gives simple access to that instance.
When should you use :
It depends on the situation.
Note : please do not use on db connection, for a detailed answer please refer to the answer of #Chad Grant
Here is a simple example of a Singleton:
public sealed class Singleton
{
private static readonly Singleton instance = new Singleton();
// Explicit static constructor to tell C# compiler
// not to mark type as beforefieldinit
static Singleton()
{
}
private Singleton()
{
}
public static Singleton Instance
{
get
{
return instance;
}
}
}
You can also use Lazy<T> to create your Singleton.
See here for a more detailed example using Lazy<T>

Here's what singleton is: http://en.wikipedia.org/wiki/Singleton_pattern
I don't know C#, but it's actually the same thing in all languages, only implementation differs.
You should generally avoid singleton when it's possible, but in some situations it's very convenient.
Sorry for my English ;)

I know it's very late to answer the question but with Auto-Property you can do something like that:
public static Singleton Instance { get; } = new Singleton();
Where Singleton is you class and can be via, in this case the readonly property Instance.

Thread Safe Singleton without using locks and no lazy instantiation.
This implementation has a static constructor, so it executes only once per Application Domain.
public sealed class Singleton
{
static Singleton(){}
private Singleton(){}
public static Singleton Instance { get; } = new Singleton();
}

E.X You can use Singleton for global information that needs to be injected.
In my case, I was keeping the Logged user detail(username, permissions etc.) in Global Static Class. And when I tried to implement the Unit Test, there was no way I could inject dependency into Controller classes. Thus I have changed my Static Class to Singleton pattern.
public class SysManager
{
private static readonly SysManager_instance = new SysManager();
static SysManager() {}
private SysManager(){}
public static SysManager Instance
{
get {return _instance;}
}
}
http://csharpindepth.com/Articles/General/Singleton.aspx#cctor

Fourth version from Implementing the Singleton Pattern in C#
One shortcut you can take with this implementation (and only this one) is to just make instance a public static readonly variable, and get rid of the property entirely. This makes the basic skeleton code absolutely tiny!
public sealed class Singleton
{
public static readonly Singleton Instance = new Singleton();
static Singleton()
{
}
private Singleton()
{
}
}

Why Singleton Lazy Instantiation over Static Initialisation Or Multi-threaded Instantiation? C#

UPDATED:
I read here https://learn.microsoft.com/en-us/previous-versions/msp-n-p/ff650316(v=pandp.10)?redirectedfrom=MSDN about 3 different ways of implementing the singleton in c#. I'm particularly interested in understanding this line:
Because the instance is created inside the Instance property method,
the class can exercise additional functionality (for example,
instantiating a subclass), even though it may introduce unwelcome
dependencies.
I understand that although lazy instantiation is not thread safe, still because it only instantiates it on demand it thus avoids instantiation every time the class is loaded. I also notice that in Lazy-instantiation I can use a non-default constructor and pass parameters whereas in Static.. But say I didn't mind it's instantiated every time it's loaded and I'm happy with a default constructor, why would I choose Lazy over static or even over the multi-threaded approach? Is there something Lazy can get me that static and multi-threaded can't? Can one be sub classed and the other not?
Also, that page seems to be saying that static initialisation is also thread-safe? Why is that? And why are they proceeding to a third multi-threaded approach if the latter is fine too?
Because the Singleton instance is referenced by a private static
member variable, the instantiation does not occur until the class is
first referenced by a call to the Instance property. This solution
therefore implements a form of the lazy instantiation property, as in
the Design Patterns form of Singleton.
(Nonetheless, I don't understand the first part of this para: if instantiation here also occurs only once as they say in a couple of paragraphs before:
"In this strategy, the instance is created the first time any member
of the class is referenced."
how is it different than the lazy approach?)
So to summarise, my question is what DOES static come to cure over the first, lazy approach and why would I still choose Lazy other than the reason that it allows me to use a none-default constructor?
Whilst I'm at it:
Consider the following two pairs of examples of Lazy vs Static, my question is, within each pair, how are they different from one another? I can see in one, the 'get' is nested within the GetInstance/Instance method but does it make any difference?
public class LazySingleton
{
private static LazySingleton _LSInstance;
private LazySingleton() { }
public static LazySingleton GetInstnace
{
get{
if (_LSInstance == null)
{
_LSInstance = new LazySingleton();
}
return _LSInstance;
}
}
}
public class LazySingleton
{
private static LazySingleton _LSInstance { get; set; }
private LazySingleton() { }
public static LazySingleton GetInstnace() {
if (_LSInstance == null)
_LSInstance = new LazySingleton();
return _LSInstance;
}
}
=======================================================
public class Singleton
{
private Singleton()
{
}
private static Singleton _LSInstance = new Singleton();
public static Singleton GetInstnace
{
get{
return _LSInstance;
}
}
}
public class Singleton
{
private Singleton() { }
private static Singleton _LSInstance = new Singleton();
public static Singleton GetInstnace()
{
return _LSInstance;
}
}
I'd really appreciate a response that can clarify this for me, thank you!

From your code, I can tell 1 difference. Let's assume to instantiate your instance, you need to wait for the system to load some data. And you're not sure the data is available when system starts (maybe few seconds later, it's available). And your service is only needed in some pages. With lazy load, you don't have any problem, since you don't use the service until some time later. But with static instantiating, you will have a problem.

Static constructor - Singleton Design pattern in c#

What if, I replaced private constructor with a static constructor in singleton Design pattern?
public sealed class Singleton
{
private static Singleton instance=null;
private Singleton()
{
}
public static Singleton Instance
{
get
{
if (instance==null)
{
instance = new Singleton();
}
return instance;
}
}
}
Static constructor will be called only once and I couldn't find any difference in the implementation. Can we replace private with static constructor?

All that the private constructor is really doing in this case is preventing anything outside of the class from instantiating an instance of class Singleton, which is almost certainly intentional as a singleton should only have a single instance.
Static class constructors are run once for a type, at an unknown time, before the type, or any of it's static members, is to be utilized. Static fields are initialized before the static constructor would be run.
So, I suppose you could replace the constructor with a static one, but that would then give you the implicit parameter-less constructor on the Singleton Type, which would allow anyone to instantiate an instance, which is likely at odds with why you are using the singleton pattern in the first place. It also wouldn't change anything about how your class was being constructed, really, so why do it?
Take the following class as an example:
public class Test { }
Under the covers, because there is no declared constructor, the C# compiler implicitly adds a parameterless, public constructor to the class, allowing consumers to create an instance.
public class Program {
public static void Main() {
var test = new Test();
}
}
This is all fine and good if you want to be able to make instances of your class. The singleton pattern intends to only provide a single instance of a type to the consumers. We could add this static instance to our test type like so:
public class Test { public static Test Instance {get;} = new Test(); }
and we would be able to get this static instance like so:
public class Program {
public static void Main() {
var test = Test.Instance; // good
var other = new Test(); // less than ideal
}
}
So we are providing access to our singleton object through it's instance field, as expected, but we can still create instances of the singleton type, which is less good, as it goes against the purpose of a singleton (namely, having only a single shared instance.)
So we add a private, parameterless constructor to the type.
public class Test {
private Test() {}
public static Test Instance {get;} = new Test();
}
Adding a constructor to a type will cause the C# compiler not to add an implicit public parameter-less constructor. Making it private allows it to be accessed within the class scope, which is used for instantiating our instance property, and prevents anything else from instantiating the object. The end result being:
public class Program {
public static void Main() {
var test = Test.Instance; // good
var other = new Test(); // Compile time error
}
}
Your singleton object now prevents other instances of the class from being instantiated, and the only way to use it is through the instance property as intended.

In simple terms, if you remove the private constructor, then anyone will be able to create a new instance of Singleton:
// With the private constructor, the compiler will prevent this code from working.
// Without it, the code becomes legal.
var newInstance = new Singleton();
And if anyone can instantiate Singleton as above, then you no longer have a singleton.

Another cleaner way to do it is to use readonly on you private instance.
This is less code and also thread safe. The CLR takes care of everything for you, no need for lock , check for null and stuff.
public sealed class Singleton
{
private static readonly Singleton _instance = new Singleton();
public static Singleton Instance {
get {
return _instance;
}
}
private Singleton()
{
}
}
Then simply test:
[TestMethod]
public void IsSingleton()
{
Assert.AreSame(Singleton.Instance, Singleton.Instance);
}
EDIT:
example using lock
public sealed class Singleton
{
private static readonly object _lock = new object();
private static Singleton instance = new Singleton();
public static Singleton Instance
{
get
{
lock(_lock)
{
if (instance==null)
{
instance = new Singleton();
}
return instance;
}
}
}
private Singleton()
{
}
}

In simplest terms, if you remove private, the default public constructor will get exposed. Then outsiders will be allowed to use new Singleton(); and make number of instances of Singleton class. So no Singleton Pattern will be there.
Additionally this classic implementation of Singleton pattern (private constructor + static getInstance() with either lazy-loading or eager loading) is so evil. In modern day you must switch to a Dependency-Injection framework instead.

This should work just fine. You could also make the class static and generic so you can store whatever kind of value in instance you want it to hold. This would facilitate the separation of concerns, keeping the singleton pattern and the class that it will contain separate.

Possible to use a singleton with a non-default constructor in C#?

This is a slight variance of this question: Possible to use a singleton with a non-default constructor in C#?
I have a class that takes parameters for it's constructor. I would like to make this singleton such that the parameters are taken upon initialising the singleton and thus would not need to be passed in each time the instance is retrieved.
My solution (which is not elegant) for this is to have a CreateInstance() static method that takes the parameters and constructs the singleton instance. I would then have another static method GetInstance() which would be parameterless to obtain the singleton instance. In code, I would then need to ensure the logic calls CreateInstance before any calls to GetInstance. However, I cannot enforce this at compile time. I can, however, check at runtime by throwing an exception in GetInstance if it is called before CreateInstance.
Is there anyway I can achieve this behaviour with compile time enforcement? Or at the very least, is there a better way of doing the same thing?

There is no way to do it at compile time, because that would be like asking the compiler "can you prove that code X is never executed before code Y is executed, in the presence of multiple threads?". It cannot be done.
As for the runtime behavior of your design, I think this is as good as it can ever be.
You can make it slightly better by exposing a Func<SingletonType> property in your singleton class. When someone asks for the singleton instance and the instance has not already been created, your class would call this "factory method" to construct the singleton. If the factory method is null, then you either throw an exception or (if applicable) construct using some default parameters.
What this does is essentially defer the construction of the singleton until it's actually needed for the first time, so it's some improvement. But the underlying principle is the same.
Update:
As LukeH points out, this is pretty much what Lazy<T> does (.NET 4 only). If possible, use that one instead of writing your own.

In a classic singleton, the real magic happens in static readonly which creates the instance as soon as it is used:
public class MySingleton
{
private static readonly _instance = new MySingleton();
private MySingleton() {}
public static MySingleton Instance
{
get
{
return _instance;
}
}
}
If you have parameters to pass to constructor, you have to implement locking yourself (note the double if sandwitching the lock):
public class MySingletonWithConstructor
{
private static _instance;
private static object _lock = new Object();
private MySingletonWithConstructor(string myArg)
{
// ... do whatever necessary
}
public static MySingletonWithConstructor Instance
{
get
{
if(_instance==null)
{
lock(_lock)
{
if(_instance==null) // double if to prevent race condition
{
_instance = new MySingletonWithConstructor("Something");
}
}
}
return _instance;
}
}
}

You could just have GetInstance() call the CreateInstance() method if the singleton object doesn't exist already.

I would do it similar to this. You may have to add locks or other things to ensure:
public class ClassA {
private static ClassA instance;
private int param;
private ClassA(int param) {
this.param = param;
}
public static ClassA getInstance() {
if (instance == null) {
throw new CustomException("Not yet initialised");
} else {
return instance;
}
}
public static void createInstance(int param) {
if (instance == null) {
instance = new ClassA(param);
}
}
}

In your GetInstance() method, why dont you just call CreateInstance if your value is null, then you have lazy initialisation..

Use CreateInstance() to be the loader of a Lazy<T> and have GetInstance return the Lazy.Value (you might want to create a static readonly field that is set to = thelazy.Value to ensure a single entry into CreateInstance())

Singleton code excerpt, an interview-question

I had another interview question. I thought this was silly, but maybe there is something I am missing. The question asked which GoF pattern this is (answer: singleton), and, if there are any problems, how I solve them.
I don't see any problems. I mentioned this is never freed and I expect that from this pattern. That is all I said. Am I missing something?
public class Class1
{
private static Class1 oInstance = null;
private Class1() { }
public static Class1 GetInstance()
{
if (oInstance == null)
{
oInstance = new Class1();
}
return oInstance ;
}
}

Thread-safety - multiple instances could be created if GetInstance() is called from competing threads.

See: An obvious singleton implementation for .NET?
There are multiple concerns you want to consider when implementing a Singleton pattern.
What happens when multiple callers request the singleton from multiple threads. It should just work.
When is the Singleton instance constructor called. You may want to defer it so it happens on the first call requesting the singleton, you may want it first instantiated at some other time.
Should people be able to inherit off your singleton class? What should the behavior be?
Should it be possible to switch your singleton instance to a different instance after the singleton has been instantiated. Answering yes to this violates the singleton pattern so in general the field holding singletons should be readonly.
API design, should you use a property or a method to return the Singleton instance.
Some people say singletons are evil. Should you even be considering it in the first place. This has been discussed quite often a good starting point is http://blogs.msdn.com/scottdensmore/archive/2004/05/25/140827.aspx
The following is a good general purpose pattern you could follow. Its thread safe, sealed, uses properties and defer instansiates the singleton.
public sealed class Singleton
{
static class SingletonCreator
{
// This may seem odd: read about this at: http://www.yoda.arachsys.com/csharp/beforefieldinit.html
static SingletonCreator() {}
internal static readonly Singleton Instance = new Singleton();
}
public static Singleton Instance
{
get { return SingletonCreator.Instance; }
}
}

Others mentioned thread safety. There's also the fact that they forgot to mark it as sealed, and so you could inherit from it and create multiple instances that way.

You have a potential race condition in multithreaded code. Two threads could each get past the null check before the constructor on the other thread is completed, so that both could end up constructing the class.

The code is not thread-safe. To make it so you need to do this:
public class Class1
{
private static Class1 oInstance = null;
private Class1() { }
public static Class1 GetInstance()
{
if (oInstance == null)
{
lock(typeof(Class1))
{
if (oInstance == null)
{
oInstance = new Class1();
}
}
}
return oInstance ;
}
}
This is the most efficient way of lazily loading the instance as it only bothers to lock (can be expensive) when it is suspected the instance won't be instantiated for the next call. Checking again once in the lock ensures it will only be instantiated once.

There is a potential issue with this if you have a multithreaded application. This can cause more than one instance to be constructed if two threads request at the same time.
I'd take a look at this page on Singletons in C#. It shows the problem in detail, as well as better options.

so is the solution the following?
public class Class1
{
private static Class1 oInstance = new Class1();
private Class1() { }
public static Class1 GetInstance()
{
return oInstance ;
}
}

Don't work at that company. The singleton pattern isn't a frequently used pattern and it's applicability in a pure OO system is questionable. Undoing a singleton pattern is a huge problem if you ever need to turn it back in to a normally constructed object.

It's missing thread-safety, this page explains it really well.