What are the real world applications of the single

Question

Duplicate

On design patterns: When should I use the singleton?

class Singleton
{
    private static Singleton instance;

    private Singleton() {}

    public static Singleton Instance
    {
        get
        {
            if (instance == null)
                instance = new Singleton();

            return instance;
        }
    }
}

Answer 1

You should use a Singleton when there should only be one instance of an object. However, Misko Hevery has some thoughts on why Singletons are bad!

Answer 2

You could find the singleton pattern useful if you have a resource that costs a lot to get initialized, and that you use several times, such as an object context when you use an ORM or a connection of some sort.

Obviously you must pay attention that keeping that thing alive does not cost you more than recreating it every time.

Answer 3

Note that this code is not thread safe:

get   
{
   if (instance == null)   
      instance = new Singleton();   
    return instance;   
}   

One thread could enter the function, get past the test for null and then be suspended. A second thread could then start and get past the null test. From that point on, both threads will at some point create their own copy of the sungleton object, only one of which gets used.

This may not matter so much in a GC language like C#, but if the singleton controls rresources other than memory, then it does matter. You need to use the double-checked locking pattern to prevent it.

Answer 4

Assuming your question is in the title:

I once worked with a COM object that could only have one instance per server. We exposed it to the entire ASP.NET application through a singleton.

Answer 5

Jon Skeet, THE_SKEET, has a great article exemplifying various ways to implement correctly (Thread safe, lazy, performant) the Singleton pattern.

Go read it here.

---

By popular demand (er... downvote) I reproduce the Skeet version:

public sealed class Singleton
{
    Singleton()
    {
    }

    public static Singleton Instance
    {
        get
        {
            return Nested.instance;
        }
    }

    class Nested
    {
        // Explicit static constructor to tell C# compiler
        // not to mark type as beforefieldinit
        static Nested()
        {
        }

        internal static readonly Singleton instance = new Singleton();
    }
}

Here, instantiation is triggered by the first reference to the static member of the nested class, which only occurs in Instance. This means the implementation is fully lazy, but has all the performance benefits of the previous ones. Note that although nested classes have access to the enclosing class's private members, the reverse is not true, hence the need for instance to be internal here. That doesn't raise any other problems, though, as the class itself is private. The code is a bit more complicated in order to make the instantiation lazy, however.

Answer 6

In my project we created a logger component which is getting used for logging in the application to different sources (e.g. text file, XML, and database, based on configurations). So there is a log manager which creates the only one instance of the logger class across the application for logging the message, errors, etc.