Design Patterns

Design patterns have picked up a lot of importance off late and rightfully so. To define design patterns in simple words they are "popular solutions for common design problems". They are very helpful in designing architecture and they also increase ease of communication among the developers. I have practically applied few design patterns myself and would like to share my knowledge with you.

To start off GOF(Gang of Four) design patterns which are considered as the foundation of design patterns have been categorized into three sections namely creational which involves creation of objects, structural and behavioral patterns. I will cover all three sections by explaining one or more patterns from each individual section.
Creational Section:

Singleton Pattern:

This is a very popular creational pattern which restricts a class to have only one instance.

Example: "Prime Minister of India" is a singleton pattern as he/she has unique responsibilities and attributes.

Implementation: A singleton class can't have a public constructor and it has to be sealed. The entry point to get the singleton instance would be a static method or a static property.

public sealed class PrimeMinister
{ private static PrimeMinister instance = new PrimeMinister(); private PrimeMinister(){ } public static PrimeMinister Instance
{ get { return instance; }
}
}

Abstract Factory Pattern:
Abstract Factory is commonly known as factory pattern. In this pattern all the classes involved implement/realize the same interface and the compiler only knows that the created object implements the specific interface but not the object's type. This is very flexible when you need to make a creation decision at runtime depending on some aspect of object's behavior rather than it's type.

Example: Imagine that there is a rental store of cars, bikes, trucks, etc but you want to deliver a vehicle depending on the customer's choice.

Implementation: Programmatically you can make a run time decision using a switch statement to return a new instance of a class which implements the specific interface depending on the customer's choice. As you can see in the constructor of "Journey" class we are getting vehicletype of the current customer and passing it to the VehicleSupplier class's static method "GetVehicle". VehicleSupplier relies on a switch statement to return the vehicle needed, so if you observe here compiler just knows that newly created object implements the "IVehicle" interface but not if it's a car, truck or a bike upfront.

public class Journey
{ public IVehicle rentedVehicle; public Journey(string customerID)
{
VehicleType vType = Customer.GetVehicleType(customerID); /*Here is the late binding. Compiler doesn't know the type of the object except that it implements the IVehicle interface*/rentedVehicle = VehicleSupplier.GetVehicle(vType);
} //Method for beginning the journey public void BeginJourney()
{ if(rentedVehicle != null)
{
rentedVehicle.Drive();
}
} //Method for parking the vehicle public void ParkTheVehicle()
{ if(rentedVehicle != null)
{
rentedVehicle.Park();
}
}
}//The class which returns the new vehicle instance depending on the //vehicle typepublic class VehicleSupplier{public static IVehicle GetVehicle(VehicleType vType)
{switch(vType)
{case VehicleType.CAR:return new Car();case VehicleType.TRUCK:return new Truck();case VehicleType.BIKE:return new Bike();
} return null;
}
} //The interface which will be implemented by Car, Truck and Bike //classespublic interface IVehicle
{void Drive();void Park();
}//enum of the vehicle typespublic enum VehicleType{CAR=1,TRUCK,BIKE};
Structural Section:
Structural patterns depend on the structure of the classes involved. There are many structural patterns like Adapter, Builder, Decorator, etc. I will explain adapter pattern with an example here.

Adapter Pattern:

By converting the interface of one class into another interface which is expected by the clients we can make incompatible classes work together and this is the adapter pattern.

Example: Consider that you bought a gadget which expects 110v power supply but you are getting 240v supply, you need to get a power adapter in this case for converting 110v to 240v. This is a perfect example for the adapter pattern. In the software context you may need to have adapters for converting data from legacy systems like AS400 to XML or some other format for export purposes.

Implementation: As you can see the "StepUpStepDownPowerAdapter" object is used for converting power supply of 240V to 110V in the "TestUSGadget" class. The "USGadget" class defines the required voltage of the gadget and other properties. The converted power supply is given to the instance of "USGadget".

/// Class for testing the gadget public class TestUSGadget
{public static void Test()
{
USGadget gadget = new USGadget();//Indian or European power supplyPowerSupply supply = new PowerSupply(VoltageTypes.V240);if(gadget.ExpectedVoltage != supply.Voltage)
{
StepUpStepDownPowerAdapter adapter = new StepUpStepDownPowerAdapter();//Getting the converted powersupply = adapter.Convert(supply,gadget.ExpectedVoltage);
gadget.Power = supply;
gadget.Start();
}
}
}public class StepUpStepDownPowerAdapter
{public StepUpStepDownPowerAdapter()
{
}//Method for coverting voltagespublic PowerSupply Convert(PowerSupply supply,VoltageTypes convertToVoltage)
{if(supply == null) return supply;//Convert iff the voltage is not in expected wayif(supply.Voltage != convertToVoltage)
supply.Voltage = convertToVoltage;return supply;
}
} /// The power supply class public class PowerSupply
{
VoltageTypes voltageType;//There will be other properties as wellpublic PowerSupply(VoltageTypes vType)
{
voltageType = vType;
}public VoltageTypes Voltage
{get{return voltageType;
}set{
voltageType = value;
}
}
}//Voltage Types enumpublic enum VoltageTypes{V110,V240};//Gadget which expects 110Vpublic class USGadget
{
VoltageTypes reqVoltage;
PowerSupply supply;public USGadget()
{
reqVoltage = VoltageTypes.V110;
}public VoltageTypes ExpectedVoltage
{get{return reqVoltage;
}
}public PowerSupply Power
{get
{return supply;
}set{
supply = value;
}
}public void Start()
{
}
}
Behavioral Section:
Behavioral Patterns define the behavior of the classes involved. The popular behavioral patterns include Chain of Responsibilities,Interpreter, Mediator, Iterator, Observer, etc. I will explain Observer pattern here.

Observer pattern involves a one-many dependency between objects where a change in an object(subject) needs to be notified to all it's dependents(observers).

Example: Consider a scenario where a job posting at some company got multiple applications. Whenever the job status changes (filled, removed or suspended) all the applicants of the job should be notified. In this case job object is subject and all the applicants are observers.

Implementation: As you can see below "Job" is the subject class and all applicants of that particular job are observers. Job class has "Add" and "Remove" methods for adding and removing applicants to it's list. Whenever job status changes all the applicant objects would be notified through Notify method which in turn calls the "Update" method of the applicant object.

/// This the subject in the observer pattern. public class Job
{private ArrayList applicants;private JobStatus statusOfJob;public Job()
{
applicants = new ArrayList();
}public void Add(Applicant candidate)
{
applicants.Add(candidate);
}public void Remove(Applicant candidate)
{
applicants.Remove(candidate);
}public void Notify()
{foreach (Applicant candidate in applicants)
{
candidate.Update(this);
}
}public JobStatus Status
{get{return statusOfJob;
}set{
statusOfJob = value;
Notify();
}
}
}//Jobstatus enumeratorpublic enum JobStatus{FILLED,SUSPENDED,REMOVED};/// This is Observer. public class Applicant
{//declare variablesstring fname;string lname;string emailID;string phoneNo;public Applicant()
{//// TODO: Add constructor logic here//}#region Properties for exposing the member variables#endregionpublic void Update(Job appliedJob)
{switch(appliedJob.Status)
{case JobStatus.FILLED://Do something like sending email, //updating database, etcbreak;case JobStatus.REMOVED://Do something like sending email, //updating database, etcbreak;case JobStatus.SUSPENDED://Do something like sending email, //updating database, etcbreak;
}//Your own functionality//End Of Functionality}
}
Conclusion
All in all design patterns are really helpful in solving design issues. Having the knowledge of various design patterns will make things much simpler whenever you come across such design problems.

Design Patterns ~ Singleton Pattern using C#

It is considered as the simplest of patterns. Main objective of singleton pattern is to restrict the instantiation of a class to a singe object. It can be implemented like this.

public class Singleton {
        private static Singleton _instance;

        private Singleton() {

        }

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

The above mentioned implementation has advantages and disadvantages. The main advantages are :

1. Since the instance is created inside the ‘Instance’ property, the class can handle additional functionality like instantiating a subclass.


2. ‘Lazy Instantiation’ approach. That is, instantiation of the class is not performed, till an object asks for an instance. This will avoid instantiating unnecessary  singletons when the application starts.

And the main disadvantage of this approach is, that this is not ideal 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)

The most common and suitable solution to overcome this is to use the ‘Double-Check Locking’. This will keep separate threads from creating new instances of the singleton at the same time.

public 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 method make sure that only one instance is created and only when the instance is required. Making the variable ‘volatile’ make sure that assignment to the instance variable completes before the instance variable can be accessed. And in order to avoid deadlocks it uses a separate object to lock on, rather than using the type itself.