Wednesday, 22 February 2017

Singleton Design Pattern

Ensure a class has only one instance and provide a global point of access to it.

What is singleton pattern?
The singleton pattern is one of the simplest design patterns:
There are only two points in the definition of a singleton design pattern,
1-there should be only one instance allowed for a class and
2-we should allow global point of access to that single instance.


This structural code demonstrates the Singleton pattern which assures only a single instance
(the singleton) of the class can be created.
 using System;  
 namespace Singleton.Structural  
 {  
  /// <summary>  
  /// MainApp startup class for Structural  
  /// Singleton Design Pattern.  
  /// </summary>  
  class MainApp  
  {  
   /// <summary>  
   /// Entry point into console application.  
   /// </summary>  
   static void Main()  
   {  
    // Constructor is protected -- cannot use new  
    Singleton s1 = Singleton.Instance();  
    Singleton s2 = Singleton.Instance();  
    // Test for same instance  
    if (s1 == s2)  
    {  
     Console.WriteLine("Objects are the same instance");  
    }  
    // Wait for user  
    Console.ReadKey();  
   }  
  }  
  /// <summary>  
  /// The 'Singleton' class  
  /// </summary>  
  class Singleton  
  {  
   private static Singleton _instance;  
   // Constructor is 'protected'  
   protected Singleton()  
   {  
   }  
   public static Singleton Instance()  
   {  
    // Uses lazy initialization.  
    // Note: this is not thread safe.  
    if (_instance == null)  
    {  
     _instance = new Singleton();  
    }  
    return _instance;  
   }  
  }  
 }  

when to use Singleton classes


A very simple example is say Logger, suppose we need to implement the logger and log it to some file according to date time. In this case, we cannot have more than one instances of Logger in the application otherwise the file in which we need to log will be created with every instance.
We use Singleton pattern for this and instantiate the logger when the first request hits or when the server is started.

Difference between static class and static method approaches:One question which a lot of people have been asking me. What’s the difference between a singleton class and a static class? The answer is static class is one approach to make a class “Singleton”.
We can create a class and declare it as “final” with all the methods “static”. In this case, you can’t create any instance of class and can call the static methods directly.

Here is how it looks:

1
2
3
4
5
6
7
8
9
10
11
public class Singleton {
   private static final Singleton instance;   
 
   private Singleton(){}
 
   public static Singleton getInstance() {
     if (instance == null)
       instance = new Singleton();
     return instance;
   }
 }

As you can see, the constructor is private, so we are unable instantiate it in the normal fashion. What you have to do is call it like this:

1
public Singleton singleton = Singleton.getInstance();

When you do this, the getInstance() method then checks to see if the parameter ‘instance’ is null. If it is, it will create a new one by calling the private constructor. After that, it just returns it. Of course, if it is not null, it just returns the existing instance of it. This insures that there is only one copy of the object within your program.

Continue Reading →

S.O.L.I.D Design Principles

S.O.L.I.D:
The First 5 Principles of Object Oriented Design

S.O.L.I.D is an acronym for the first five object-oriented design(OOD) principles

These principles, when combined together, make it easy for a programmer to develop
software that are easy to maintain and extend. They also make it easy for developers
to avoid code smells, easily refactor code, and are also a part of the agile or adaptive
software development.

S.O.L.I.D STANDS FOR:

When expanded the acronyms might seem complicated, but they are pretty simple to grasp.

S – Single-responsiblity principle
O – Open-closed principle
L – Liskov substitution principle
I – Interface segregation principle
D – Dependency Inversion Principle

Let’s look at each principle individually to understand why S.O.L.I.D can help make us
better developers.

Single-responsibility Principle
S.R.P for short – this principle states that:

A class should have one and only one reason to change, meaning that a class should have
only one job.

A typical example could a EmailSender class:
this should just deal with sending an email out. this should not be responsible for loading the email content from database or even formatting the email content to be sent.

Open-closed Principle

Objects or entities should be open for extension, but closed for modification. This simply
means that a class should be easily extendable without modifying the class itself.

Liskov substitution principle

All this is stating is that every subclass/derived class should be substitutable for their
base/parent class.

Interface segregation principle

A client should never be forced to implement an interface that it doesn’t use or clients
shouldn’t be forced to depend on methods they do not use.

Dependency Inversion principle
Entities must depend on abstractions not on concretions. It states that the high level module must not depend on the low level module, but they should depend on abstractions.

Reference: Click here


Continue Reading →

Topics

ADO .Net (2) Ajax (1) Angular Js (17) Angular2 (24) ASP .Net (14) Azure (1) Breeze.js (1) C# (49) CloudComputing (1) CMS (1) CSS (2) Design_Pattern (3) DI (3) Dotnet (21) Entity Framework (3) ExpressJS (4) Html (3) IIS (1) Javascript (6) Jquery (9) Lamda (3) Linq (11) Mongodb (1) MVC (48) NodeJS (7) RDLC (1) Report (1) Sql Server (29) SSIS (3) SSRS (2) UI (1) WCF (12) Web Api (10) Web Service (1) XMl (1)