Singleton as a static class

 
129   96.7
Feb 02, 2010
 
I was wondering why are Singletons not implemented as a static class with a static public Instance property?



130   96.8
Feb 17, 2010
I will talk only about one perspective as right now only this hit my mind ;)

Let's say your singleton class is per context base. Take for an example your ShoppingCart class, and for it you need to have only one instance per customer session. Obviously a simple static class won't do here. Singleton is all about having the same "INSTANCE" throughout a particular context.

And why will we like to do that. Well in this particular scenario we are doing it for state management as the same instance is entertaining different requests so we can have ShoppingCart data through out that session.

310   99.8
Feb 17, 2010
The primary reason you wouldn't use a Singleton as a static class has to do with the potential for multi-threading issues. Note the following quote from http://msdn.microsoft.com/en-us/library/ms998558.aspx. If

===================================================================
Static Initialization

One of the reasons Design Patterns [Gamma95] avoided static initialization is because the C++ specification left some ambiguity around the initialization order of static variables. Fortunately, the .NET Framework resolves this ambiguity through its handling of variable initialization:

Copy Code
public sealed class Singleton { private static readonly Singleton instance = new Singleton(); private Singleton(){} public static Singleton Instance { get { return instance; } } }

In this strategy, the instance is created the first time any member of the class is referenced. The common language runtime takes care of the variable initialization. The class is marked sealed to prevent derivation, which could add instances. For a discussion of the pros and cons of marking a class sealed, see [Sells03]. In addition, the variable is marked readonly, which means that it can be assigned only during static initialization (which is shown here) or in a class constructor.

This implementation is similar to the preceding example, except that it relies on the common language runtime to initialize the variable. It still addresses the two basic problems that the Singleton pattern is trying to solve: global access and instantiation control. The public static property provides a global access point to the instance. Also, because the constructor is private, the Singleton class cannot be instantiated outside of the class itself; therefore, the variable refers to the only instance that can exist in the system.

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.

The only potential downside of this approach is that you have less control over the mechanics of the instantiation. In the Design Patterns form, you were able to use a nondefault constructor or perform other tasks before the instantiation. Because the .NET Framework performs the initialization in this solution, you do not have these options. In most cases, static initialization is the preferred approach for implementing a Singleton in .NET.

Multithreaded Singleton

Static initialization is suitable for most situations. When your application must delay the instantiation, use a non-default constructor or perform other tasks before the instantiation, and work in a multithreaded environment, you need a different solution. Cases do exist, however, in which you cannot rely on the common language runtime to ensure thread safety, as in the Static Initialization example. In such cases, you must use specific language capabilities to ensure that only one instance of the object is created in the presence of multiple threads. One of the more common solutions is to use the Double-Check Locking [Lea99] idiom to keep separate threads from creating new instances of the singleton at the same time.

Note: The common language runtime resolves issues related to using Double-Check Locking that are common in other environments. For more information about these issues, see "The 'Double-Checked Locking Is Broken' Declaration," on the University of Maryland, Department of Computer Science Web site, at http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html.

The following implementation allows only a single thread to enter the critical area, which the lock block identifies, when no instance of Singleton has yet been created:

Copy Code using System; public sealed class Singleton { private static volatile Singleton instance; private static object syncRoot = new Object(); private Singleton() {} public static Singleton Instance { get { if (instance == null) { lock (syncRoot) { if (instance == null) instance = new Singleton(); } } return instance; } } }

This approach ensures that only one instance is created and only when the instance is needed. Also, the variable is declared to be volatile to ensure that assignment to the instance variable completes before the instance variable can be accessed. Lastly, this approach uses a syncRoot instance to lock on, rather than locking on the type itself, to avoid deadlocks.

This double-check locking approach solves the thread concurrency problems while avoiding an exclusive lock in every call to the Instance property method. It also allows you to delay instantiation until the object is first accessed. In practice, an application rarely requires this type of implementation. In most cases, the static initialization approach is sufficient.

Resulting Context

Implementing Singleton in C# results in the following benefits and liabilities:

Benefits

  • The static initialization approach is possible because the .NET Framework explicitly defines how and when static variable initialization occurs.

  • The Double-Check Locking idiom described earlier in "Multithreaded Singleton" is implemented correctly in the common language runtime.

    Liabilities

    If your multithreaded application requires explicit initialization, you have to take precautions to avoid threading issues.


  • 50   50
    Jan 26, 2012
    you can not create instance for static class, but singleton pattern maintains single instance

    http://www.dotnetquestionanswers.com/

    80   96.3
    Mar 07, 2010
    The Singleton pattern has several advantages over static classes. First, a singleton can extend classes and implement interfaces, while a static class cannot (it can extend classes, but it does not inherit their instance members). A singleton can be initialized lazily or asynchronously while a static class is generally initialized when it is first loaded, leading to potential class loader issues. However the most important advantage, though, is that singletons can be handled polymorphically without forcing their users to assume that there is only one instance
     1 comment
     
    Exactly --- Zac Bai  Mar 09, 2010

    50   50
    Feb 04, 2010

    Singleton pattern ensure that there would be only one class instance available at any point in time but you can not create instance of a class( even a single instance) which is maked as a static.

     4 comments
     
    This is not correct. A class exist when called upon. This is what the static constructor is all about. --- Hans Overkamp  Feb 17, 2010
     
    If we have static class then why do we need to creae instance..? --- Ashok Gupta  Mar 12, 2010
     
    As per the technical description of static class, we can't create the instance of static class. --- Dnyaneshwar Bhamare  Feb 16, 2012
     
    so the main question remains as it is "I was wondering why are Singletons not implemented as a static class with a static public Instance property?" --- Sajjad Ahmad  Apr 18, 2012