Wednesday 22 February 2017

Singleton Design Pattern

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.

Here is how it looks:
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:
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.

Singleton Pattern Versus Static Class-
The Singleton pattern has several advantages over static classes.
Your code will be more flexible if you are using a singleton class and another 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 the possibility that our application has a global shared object and tomorrow you decide that you must make more than one instance of the class.
If you use a singleton class then all you have to do is make the constructor public. This is not so simple with static classes.

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

See the below difference:

Static Class:-
  1. You cannot create the instance of static class.
  2. Loaded automatically by the .NET Framework common language runtime (CLR) when the program or namespace containing the class is loaded.
  3. Static Class cannot have constructor.
  4. We cannot pass the static class to method.
  5. We cannot inherit Static class to another Static class in C#.
  6. A class having all static methods.
  7. Better performance (static methods are bonded on compile time)
Singleton:-
  1. You can create one instance of the object and reuse it.
  2. Singleton instance is created for the first time when the user requested.
  3. Singleton class can have constructor.
  4. You can create the object of singleton class and pass it to method.
  5. Singleton class does not say any restriction of Inheritance.
  6. We can dispose the objects of a singleton class but not of static class.
  7. Methods can be overridden.
  8. Can be lazy loaded when need (static classes are always loaded).
  9. We can implement interface(static class can not implement interface).


Continue Reading →

SOLID 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

SOLID Principles is a coding standard that all developers should have a clear concept for developing software in a proper way to avoid a bad design.
When the developer builds a software following the bad design, the code can become inflexible and more brittle, small changes in the software can result in bugs. For these reasons, we should follow SOLID Principles.

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.

Example:  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.
Creating new extension methods are the example of this principles.

Example: See the below code, there are 2 types of customer New and Existing, we have implemented If and Else for both customer. This is Ok if we have only these two type of customer.
class Customer
{
    int Type;
    void Add()
    {
        if (Type == 0)
        {
            Console.Write("AddNewCustomer");
        }
        else
        {
            Console.Write("AddExistingCustomer");
        }
    }
}

But what If we have to add new type? Here we modify our code to implement OCP, See the below code: 
public class CustomerBetter
    {
        public virtual void Add()
        {
            Console.Write("AddNewCustomer");
        }
    }

    class ExistingCustomer : CustomerBetter
    {
        public override void Add()
        {
            Console.Write("ExistingCustomer");
        }
    }

    class AnotherCustomer : CustomerBetter
    {
        public override void Add()
        {
            Console.Write("AnotherCustomer");
        }
    }

Liskov substitution principle

All this is stating is that every subclass/derived class should be substitutable for their
base/parent class. https://medium.com/swlh

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.

Example: We have one interface ICustomer which have two function Add() and Read().   Customer1 class implementing the ICustome interface. This works perfectly fine here.

interface ICustomer 
{
    void Add();
    void Read();
}

class Customer1 : ICustomer
{
    void Add()
    {
        // Add functionality here!
    }

    void Read()
    {
        // Read functionality here!
    }
}

Now we have another customer named Customer2 who wants to implement only Add() function from interface ICustomer . With the current interface It's not possible. Let's break the interface for two classes.
interface ICustomer 
{
    void Add();
}

interface ICustomerV2 
{
    void Read();
}

class Customer1 : ICustomerICustomerV2 
{
  // Implement Add and read function both
}

class Customer2 : ICustomer
{
  // Implement only Add function
}
Examples can be seen herehttps://github.com/

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.

If we don’t follow SOLID Principles we  
1. End up with tight or strong coupling of the code with many other modules/applications
2. Tight coupling causes time to implement any new requirement, features or any bug fixes and some times it creates unknown issues
3. End up with a code which is not testable
4. End up with duplication of code
5. End up creating new bugs by fixing another bug
6. End up with many unknown issues in the application development cycle

Following SOLID Principles helps us to  
1. Achieve reduction in complexity of code
2. Increase readability, extensibility and maintenance
3. Reduce error and implement Reusability
4. Achieve Better testability
5. Reduce tight coupling



Continue Reading →

Topics

ADFS (1) ADO .Net (1) Ajax (1) Angular (43) Angular Js (15) ASP .Net (14) Authentication (4) Azure (3) Breeze.js (1) C# (47) CD (1) CI (2) CloudComputing (2) Coding (7) CQRS (1) CSS (2) Design_Pattern (6) DevOps (4) DI (3) Dotnet (8) DotnetCore (16) Entity Framework (2) ExpressJS (4) Html (4) IIS (1) Javascript (17) Jquery (8) Lamda (3) Linq (11) microservice (3) Mongodb (1) MVC (46) NodeJS (8) React (11) SDLC (1) Sql Server (32) SSIS (3) SSO (1) TypeScript (1) UI (1) UnitTest (1) WCF (14) Web Api (15) Web Service (1) XMl (1)

Dotnet Guru Archives