Singleton vs static class

      Comments Off on Singleton vs static class

Home Forums Programming Software engineering Patterns design Singleton vs static class

This topic contains 0 replies, has 1 voice, and was last updated by  Васильев Владимир Сергеевич 2 weeks ago.

  • Author
    Posts
  • #4098

    The famous design pattern Singleton, which prohibits the creation of more than one instance of a class is rather easy to implement, and therefore many believe there is nothing special to talk about it.

    But I have to admit that I personally have a lot of questions on the topic.

    Let’s say here in this article I’m just expounding my own vision of some details about Singleton design pattern, and you correct me if you don’t agree on something.

    The question that I want to raise – what is the difference between the use of a Singleton pattern and a static class? And can a static class be considered a special case of a Singleton pattern?

    That is what we are going to discuss here.

    Let’s start with the implementation.

    Singleton offers an implementation of a class, in which you can instantiate it only once. Let’s see how it is implemented in the C# language:

    class Singleton
    {  
       static Singleton obj;    
       public static Singleton Obj { get { return obj; } }   
       public string Data { get; set; }     
       static Singleton()  
       {  
          obj = new Singleton();  
       }   
       private Singleton()  
       {
          Data = "I am a singleton";  
       }
    }

    We define a class with a private parameterless constructor, which makes it impossible to call it from outside the class. In this case, we still have the ability to create instances of this class withing the class itself. So we define a reference to this class as a private field. Then we assign it in the static constructor, which as we know is performed only once, and before the instance constructor. Then we define a public property to give an access to a private field and set a static modifier to both field and a property.

    To the field – so that you can refer to it within the static constructor, to the property – so that you can access it through the class name, without creating an instance.

    So as you can see, the implementation is simple.

    To see how it’s working we can create any number of references to the Singleton instance, but they will all refer to the same object in memory.

    class Program
    {  
       static void Main(string[] args)   
       {  
          Singleton s1 = Singleton.Obj;  
          Console.WriteLine(s1.Data);   
       }
    }

    Well, as for implementation, all is working well.

    Now let’s have a look at a static class.

    static class StaticData
    {  
       public static string Data { get; set; }    
       static StaticData()  
       {  
          Data = "I am a static class data";  
       }
    }

    To make any class static, it is enough to add the modifier static to its definition and then it will be impossible to create an instances . All members of this class will also be explicitly defined as static. Access to all members of this class is only possible through its name, which means only public data and methods will be available.

    It is impossible to create an instance of a static class but it provides an access to its data and methods wherever it is needed.

    class Program
    {  
       static void Main(string[] args)  
       {    
          Console.WriteLine(StaticData.Data);  
       }
    }

    And then the question arises – why not use static classes as Singleton classes or instead of them or at least why not consider them as another way to implement Singleton pattern?

    In fact, the answer is very simple. The main difference lies in the formulation of Singleton pattern itself – we need an INSTANCE (though only one). In the case of a static class there can be NO INSTANCES (neither today nor tomorrow).

    The idea of ​​ static classes appeared on a base of a C# language paradigm about the absence of global data, because this is a 100% object-oriented language. So placing data in a static classis in fact a way to bypass it. This class can just combine variables and methods under a single identifier and provide access to them at any point in the code of any class.

    In the case of a Singleton, we need an instance to give an access to its data and functionality. And then we can pass this instance to parameters of functions when it is needed.

    We can define any number of base interfaces for Singleton classes. As for static classes no base interfaces can be specified.

    In terms of creating heirs they are equal: neither a Singleton class, nor a static class can be inherited. (But at least Singleton can be aggregated, so its reference can be a field of a class which needs its functionality).

    Another advantage of a Singleton class is that it can be serialized, and thus transmitted over network, stored in a file or a database.

    You can not directly save the state of data of a static class. Although, if you change its data frequently, and these changes need to be committed, there is, for example, Memento pattern.

    However, generally, static classes contains data that are not changing frequently, but can be read by other classes.

    Also there is some control over the lifetime of a Singleton object, because it can be created only when needed (lazy instantiation) and deleted from the memory earlier than the static class data.

    The Singleton itself can be used as a part of other design patterns. For example, products created by the abstract factory can be represented by instances of different Singleton classes.

    I think these differences is enough to decide what to use in specific situations – a Singleton or a static class.

    Now I have answers to my own questions. As for yours I will be glad to answer them all.

    Thank you for your attention;)

You must be logged in to reply to this topic.