Monday, July 23, 2012

Singleton Vs. Static Classes



Many of us have used static and singleton classes in our projects. Some of the times people ask us “Why do you use Singleton class if a Static class serves the purpose?” Or someone might have asked you at least once “What is difference between Singleton and Static classes and when do you go for each one in your program?” I have been asked in many times by friends and in some of the interviews (most of the times) and so thought of putting whatever is in my mind on this. It might help anyone like me. You are free to add, suggest or comment on this post and your ideas are very much welcome.

Static and Singleton are very different in their usage and implementation. So we need to wisely choose either of these two in our projects.

Let us discuss more about Singleton class first.

Singleton is a design pattern that makes sure that your application creates only one instance of the class anytime. It is highly efficient and very graceful. Singletons have a static property that you must access it to get the object reference. So you are not instantiating an object like how we do for a normal class.

We go through the following code and learn more about normal class usage, static class usage and about the singleton class:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
 
namespace SingletonVsStaticClass
{
    class SomeClass
    {
        public int ABC;
    }
 
    public sealed class SingletonSampleClass
    {
        static  SingletonSampleClass _instance;
 
        public static SingletonSampleClass Instance
        {
            get { return _instance ?? (_instance = new SingletonSampleClass()); }
        }
        private SingletonSampleClass() { }
 
        public string Message { getset; }
    }
 
    static public class StaticSampleClass
    {
        private static readonly int SomeVariable;
        //Static constructor is executed only once when the type is first used. 
        //All classes can have static constructors, not just static classes.
        static StaticSampleClass()
        {
            SomeVariable = 1;
            //Do the required things
        }
        public static string ShowValue()
        {
            return string.Format("The value of someVariable is {0}", SomeVariable);
        }
        public static string Message { getset; }
    }
    class Program
    {
 
        static void Main(string[] args)
        {
            //Normal class instantiation and usage
            var someClass = new SomeClass {ABC = 5};
            Console.WriteLine("Normal class usage: "+someClass.ABC);
 
            //Static Class instantiation
            string returnValue = StaticSampleClass.ShowValue();
            Console.WriteLine("Static class usage: " + returnValue);
 
            //Singleton class instantiation
            var singletonSampleClass = SingletonSampleClass.Instance;
            singletonSampleClass.Message = "Hello";
            Console.WriteLine("Singleton class usage: " + singletonSampleClass.Message);
            
            //Test the instances if are equal
            var anotherSingletonSampleClass = SingletonSampleClass.Instance;
            Console.WriteLine("Checking if both instances are same: "+ singletonSampleClass.Equals(anotherSingletonSampleClass) );
 
            Console.Read();
        }
    }
}




You saw how to use properties and methods for different types of classes. For normal class, we need to create an object first to use its properties and methods. For static classes we do not need to instantiate and we access properties and methods by class name. For singleton classes, we create an instance using its static property and at any time it creates a single instance of a class. You should have checked in the above example that even you try to create multiple instances of a singleton class, it returns you the same instance that is created for the first time.

When shall we use singleton class and when to go for static classes?

Static classes are basically used when you want to store single instance, data which should be accessed globally throughout your application. The class will be initialized at any time but mostly it is initialized lazily. Lazy initialization means it is initialized at the last possible moment of time. There is a disadvantage of using static classes. You can never be able to change how it behaves after once the class is decorated with static key word.

Singleton Class instance can be passed as a parameter to another method whereas static class cannot:

Singleton class does not require you to use the static key word everywhere.  Static class objects cannot be passed as parameters to other methods where we can pass instances of singleton as a parameter to another method.

For example we can modify our normal class to have a method which takes a singleton class instance as a parameter. We cannot do this with static classes.

 class SomeClass
    {
        public int ABC;
 
        public void SingletonMethod(SingletonSampleClass singletonSampleClass)
        {
            
        }
    }

var someClass = new SomeClass {ABC = 5};
 someClass.SingletonMethod(anotherSingletonSampleClass);

Singleton classes support Interface inheritance whereas a static class cannot implement an interface:

Let us try to create an interface and see if we can make our 3 classes to implement it.

 public interface IMyInterface
    {
        void MyInterfaceMethod();
    }
    class SomeClass : IMyInterface
    {
        public int ABC;
 
        public void SingletonMethod(SingletonSampleClass singletonSampleClass)
        {
            
        }
 
        public void MyInterfaceMethod()
        {
            throw new NotImplementedException();
        }
    }
 
    public sealed class SingletonSampleClass : IMyInterface
    {
        static  SingletonSampleClass _instance;
 
        public static SingletonSampleClass Instance
        {
            get { return _instance ?? (_instance = new SingletonSampleClass()); }
        }
        private SingletonSampleClass() { }
 
        public string Message { getset; }
 
        public void MyInterfaceMethod()
        {
            throw new NotImplementedException();
        }
    }
 
    static public class StaticSampleClass:IMyInterface
    {
        private static readonly int SomeVariable;
        //Static constructor is executed only once when the type is first used. 
        //All classes can have static constructors, not just static classes.
        static StaticSampleClass()
        {
            SomeVariable = 1;
            //Do the required things
        }
        public static string ShowValue()
        {
            return string.Format("The value of someVariable is {0}", SomeVariable);
        }
        public static string Message { getset; }
    }

When we are trying to make the static class implement the interface, it gives the following exception:

SingletonVsStaticClass.StaticSampleClass': static classes cannot implement interfaces

This is because static classes cannot implement interfaces.

Since singleton class supports interface implementation, we can reuse our singleton for any number of implementations of interface confirming objects.

CustomMethod((IMyInterface)singletonSampleClass);

Your code will be more flexible if you are using a singleton class and other advantage is that the code that uses the singleton does not need to know if it is a singleton object or a transient object. Using a static means you have to call static methods explicitly. Static classes also fail during dependency injection.
There is a general problem that I have read somewhere in one of the articles. Consider our application has a global shared object and tomorrow you decide that you have to make more than one instance of the class.
If you use a singleton class all you have to do is make the constructor public. This is not so simple with static class.

During my initial days of career, I have created a static class and have set a property for a page heading. So, each page while loading sets the page heading and uses the same page heading for consecutive pages throughout the web application. Based on the user’s selection at login, each user will have different heading set and the same should be displayed till he logs out. There are two issues seen in this case. One is the heading changes for all the users when one someone logins with different option. And also, till the server is restarted or all the applications closed, the static variables cannot be reset. This is a problem in web applications. So, we need to be careful with static variables and static methods in web applications.
The advantage of using static class is the compiler makes sure that no instance methods are accidentally added. The compiler guarantees that instances of the class cannot be created.

A singleton class has a private constructor that prevents the class from instantiated. A singleton class can have instance members while a static class cannot.

Thread safe for singleton class instantiation:
The following is beautifully explained in the MSDN and I am pasting the content from the MSDN site here. You can access the content from the url http://msdn.microsoft.com/en-us/library/ff650316.aspx

Even though Singleton is a comparatively simple pattern, there are various tradeoffs and options, depending upon the implementation. The following is a series of implementation strategies with a discussion of their strengths and weaknesses.

Singleton

The following implementation of the Singleton design pattern follows the solution presented in Design Patterns: Elements of Reusable Object-Oriented Software [Gamma95] but modifies it to take advantage of language features available in C#, such as properties:


using System;

public class Singleton
{
   private static Singleton instance;

   private Singleton() {}

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

This implementation has two main advantages:
  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.
  The instantiation is not performed until an object asks for an instance; this approach is referred to as lazy instantiation. Lazy instantiation avoids instantiating unnecessary singletons when the application starts.
The main disadvantage of this implementation, however, is that it is not safe for multithreaded environments. If separate threads of execution enter the Instance property method at the same time, more that one instance of the Singleton object may be created. Each thread could execute the following statement and decide that a new instance has to be created:

if (instance == null)
Various approaches solve this problem. One approach is to use an idiom referred to as Double-Check Locking [Lea99]. However, C# in combination with the common language runtime provides a static initializationapproach, which circumvents these issues without requiring the developer to explicitly code for thread safety.

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:


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:


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.



Sunday, July 22, 2012

Difference between Throw exception and Throw



I know most of the programmers including me use Throw exception and Throw in our daily programming and we never see any side effects because of our usage. But best practices always say that we need to know what is good for a particular situation. And often many programmers gets confused between the two though they feel they know it. In fact I also think the same.

Basic difference is Throw exception overwrites the stack trace and this makes it hard to find the original code line number that has thrown the exception.

Throw basically keeps up the stack information and adds it stack information in the exception that it is throwing.

Let us see what it means rather speaking so many words to better understand the differences. I am using a console application to easily test and see how the usage of two differs in their functionality.

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

namespace TestingThrowExceptions
{
    class Program
    {
        public void ExceptionMethod()
        {
            throw new Exception("Original Exception occurred in ExceptionMethod");

        }

        static void Main(string[] args)
        {
            Program p = new Program();
            try
            {
                p.ExceptionMethod();
            }
            catch (Exception ex)
            {
                
                throw ex;
            }
        }
    }
}

Now run the code by pressing F5 button the key board and see what happens. It returns an exception and look at the stack trace.

System.Exception was unhandled
  Message=Original Exception occurred in ExceptionMethod
  Source=TestingThrowExceptions
  StackTrace:
       at TestingThrowExceptions.Program.Main(String[] args) in C:\TestProjects\TestingThrowExceptions\TestingThrowExceptions\Program.cs:line 26

You find that the exception source is shown as Main method in the program.cs at line 26.

Now change the code with Throw instead of Throw exception and see what happens.

  Message=Original Exception occurred in ExceptionMethod
  Source=TestingThrowExceptions
  StackTrace:
       at TestingThrowExceptions.Program.ExceptionMethod() in C:\TestProjects\TestingThrowExceptions\TestingThrowExceptions\Program.cs:line 12
       at TestingThrowExceptions.Program.Main(String[] args) in C:\TestProjects\TestingThrowExceptions\TestingThrowExceptions\Program.cs:line 26

Now the stack trace shows that the exception original source is ExceptionMethod() and then it shows the Main method.

If you observe both the stack traces the first one in blue (for Throw Exception) and the second one in Green (for Throw), you will find that the first one has truncated the original stack trace and throwing the exception as if it is a source for the exception.

Basically in MSIL there are two types of instructions, Throw and reThrow. “Throw exception” is compiled into Throw instruction and “Throw” is compiled into rethrow.

So any time you re throw the exception using “Throw” statement it preserves the original stack trace and if you re throw the exception using “Throw ex” the stack trace is reset to the point where the exception has been thrown.

Now I have modified to see what happens if the code has more than one source of exception.
 class Program
    {
        public void AnotherMethod()
        {
            Program p = new Program();
            try
            {
                p.ExceptionMethod();
            }
            catch (Exception ex)
            {
 
                throw;
            }
 
        }
        public void ExceptionMethod()
        {
            throw new Exception("Original Exception occurred in ExceptionMethod");
 
        }
 
        static void Main(string[] args)
        {
            Program p = new Program();
            try
            {
                p.AnotherMethod();
            }
            catch (Exception ex)
            {
                
                throw;
            }
        }
    }

I have added a method called “AnotherMethod()” which calls the method “ExceptionMethod()” and the method “AnotherMethod()” has been called in Main method to check if still the original stack trace is preserved and here is the stack trace we got when we ran the program:

  Message=Original Exception occurred in ExceptionMethod
  Source=TestingThrowExceptions
  StackTrace:
       at TestingThrowExceptions.Program.ExceptionMethod() in C:\TestProjects\TestingThrowExceptions\TestingThrowExceptions\Program.cs:line 26
       at TestingThrowExceptions.Program.AnotherMethod() in C:\TestProjects\TestingThrowExceptions\TestingThrowExceptions\Program.cs:line 20
       at TestingThrowExceptions.Program.Main(String[] args) in C:\TestProjects\TestingThrowExceptions\TestingThrowExceptions\Program.cs:line 40

You observer that it has listed the source in order first one as ExceptionMethod and then followed by AnotherMethod and then by Main method.

So, then the question comes in our mind is when shall we use the “Throw ex” in our code? The answer is when you want to throw a meaningful exception to the calling method or code where the exception has been thrown by the source of the exception. Then the second question is then how can we make sure that what code in our program has raised an exception? The answer is by adding the original exception as the inner exception.

Let us see it how by modifying the “Throw” in all of our methods to “Throw exception” and add the original one as an inner exception.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
 
namespace TestingThrowExceptions
{
    class Program
    {
        public void AnotherMethod()
        {
            Program p = new Program();
            try
            {
                p.ExceptionMethod();
            }
            catch (Exception ex)
            {
 
                throw new ApplicationException("operation failed",ex);
            }
 
        }
        public void ExceptionMethod()
        {
            throw new Exception("Original Exception occurred in ExceptionMethod");
 
        }
 
        static void Main(string[] args)
        {
            Program p = new Program();
            try
            {
                p.AnotherMethod();
            }
            catch (Exception ex)
            {
                
                throw new ApplicationException("Could not get data",ex);
            }
        }
    }
}

Let us see the stack trace by running the program:
  Message=Could not get data
  Source=TestingThrowExceptions
  StackTrace:
  (3)     at TestingThrowExceptions.Program.Main(String[] args) in C:\TestProjects\TestingThrowExceptions\TestingThrowExceptions\Program.cs:line 40
……
  InnerException: System.ApplicationException
       Message=operation failed
       Source=TestingThrowExceptions
       StackTrace:
       (2)     at TestingThrowExceptions.Program.AnotherMethod() in C:\TestProjects\TestingThrowExceptions\TestingThrowExceptions\Program.cs:line 20
     (3)       at TestingThrowExceptions.Program.Main(String[] args) in C:\TestProjects\TestingThrowExceptions\TestingThrowExceptions\Program.cs:line 35
       InnerException:
            Message=Original Exception occurred in ExceptionMethod
            Source=TestingThrowExceptions
            StackTrace:
              (1)   at TestingThrowExceptions.Program.ExceptionMethod() in  C:\TestProjects\TestingThrowExceptions\TestingThrowExceptions\Program.cs:line 26
          (2)       at TestingThrowExceptions.Program.AnotherMethod() in C:\TestProjects\TestingThrowExceptions\TestingThrowExceptions\Program.cs:line 15
            InnerException:

So, on looking at the stack trace, you can still be able to find out where the exception has originally occurred.

If your application stores the meaningful application in database or is to be displayed to the user on UI screen we should follow this method and the actual stack trace should be logged in a log file for debugging the code.