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 type
public 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 //classes
public interface IVehicle
{
void Drive();
void Park();
}
//enum of the vehicle types
public 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 supply
PowerSupply supply = new PowerSupply(VoltageTypes.V240);
if(gadget.ExpectedVoltage != supply.Voltage)
{
StepUpStepDownPowerAdapter adapter = new StepUpStepDownPowerAdapter();
//Getting the converted power
supply = adapter.Convert(supply,gadget.ExpectedVoltage);
gadget.Power = supply;
gadget.Start();
}
}
}
public class StepUpStepDownPowerAdapter
{
public StepUpStepDownPowerAdapter()
{
}
//Method for coverting voltages
public PowerSupply Convert(PowerSupply supply,VoltageTypes convertToVoltage)
{
if(supply == null) return supply;
//Convert iff the voltage is not in expected way
if(supply.Voltage != convertToVoltage)
supply.Voltage = convertToVoltage;
return supply;
}
}
/// The power supply class
public class PowerSupply
{
VoltageTypes voltageType;
//There will be other properties as well
public PowerSupply(VoltageTypes vType)
{
voltageType = vType;
}
public VoltageTypes Voltage
{
get
{
return voltageType;
}
set
{
voltageType = value;
}
}
}
//Voltage Types enum
public enum VoltageTypes{V110,V240};
//Gadget which expects 110V
public 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 enumerator
public enum JobStatus{FILLED,SUSPENDED,REMOVED};
/// This is Observer.
public class Applicant
{
//declare variables
string fname;
string lname;
string emailID;
string phoneNo;
public Applicant()
{
//
// TODO: Add constructor logic here
//
}
#region Properties for exposing the member variables
#endregion
public void Update(Job appliedJob)
{
switch(appliedJob.Status)
{
case JobStatus.FILLED:
//Do something like sending email, //updating database, etc
break;
case JobStatus.REMOVED:
//Do something like sending email, //updating database, etc
break;
case JobStatus.SUSPENDED:
//Do something like sending email, //updating database, etc
break;
}
//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.