Basically design patterns are nothing but experiences of programmers accumulated over long periods of time by experienced programmers( specially from the feedbacks of guys who take the handover from the senior pros ). Everyone who have done their bit in coding knows that taking a handover and working your way out with the code in a tight deadline schedule is more traumatizing and challenging than actually writing the code from the scratch. In fact sometimes the project manager actually decides to scrap the old code and write the code from scratch, but this is a very precarious balancing act as the man/hour cost of the previously written code gets nullified and on top the new code writing schedule can disturb the on going processes. In view of this, the design patterns if implemented right from the architecture stage correctly, could save huge amounts of time and money.
Anyway now without wasting any more time, I will try and revisit the stuff for all of us.....
Here are some commonly used Design Patterns used in OOPS,
1. The Singleton Pattern
A singleton pattern is basically a substitute for global variables, the usage of which can help in demolishing the quick code scattering in your dream program. Usually a singleton class will have a protected or private constructor, a private Instance variable and a method which will return the instance variable.
Class _Singleton
{
private:
static _Singleton *m_Instance;
static int m_iNoOfHits;
_Singleton( void );
public:
_Singleton * GetInstance( void );
int GetNoOfHits( void );
void IncrementHits(void);
};
_Singleton :: Singleton( void )
{
if( !m_Instance )
m_Instance = new _Singleton;
}
_Singleton * _Singleton :: GetInstance( void )
{
return m_Instance;
}
void _Singleton :: IncrementHits( void )
{
++m_iNoOfHits;
}
int _Singleton :: GetNoOfHits( void )
{
return m_iNoOfHits;
}
This seemingly innocuous methodology can be used to great extends for e.g. while having a single database connection, or simultaneously handling multiple connection requests from clients.
2. The Abstract Factory Pattern
In theory, the abstract factory provides an interface which selects the objects needed to be instantiated by the client code instead of the client code directly doing the same, thus freeing the client code from the responsibility of knowing what is going on under the hood of the other section of the code. It improves the understandability of the code and also helps in separating the two aspects of the code.
Let's take an example, Suppose in a petrol pump dispensing unit we have 3 serial ports on the microcontroller and further these 3 ports are wired up to be used as follows:
Port 1: Printer Port No 1
Port 2 : Printer Port No 2
Port 3 : Automation Port
Now after a dispensing is over, the resultant data is to be sent to one of the ports depending on the configuration, Let's see how we can achieve it using the abstract factory methodology,
class Port // Abstract class
{
public:
virtual SendData() = 0;
};
class PrinterPort1 : Port
{
public:
SendData();
};
class PrinterPort2 : Port
{
public:
SendData();
};
class AutomationPort : Port
{
public:
SendData();
};
class DataFactory
{
public:
SendDispensedData( int iPortNo);
};
DispenseOver()
{
int iPortNo;
DataFactory dataFactory;
iPortNo = GetPort();
dataFactory.SendDispensedData( iPortNo );
}
In the above example, the SendDispensedData function in DataFactory, selects the object to instantiate based on the port number given to it, thus segregating the port modules from the rest of the code sections.
3. The Builder Pattern
Basically, there are 3 things at play here,
1. The Builder
2. The Director
3. The Product
This pattern is used when the construction of a process is complicated, the pattern then segregates this construction process is such a way that it can be used again. Let's take a simple example, which would help us in getting a grasp,
Suppose we have a Invoice generation implementation, which can be exported onto an excel or a pdf format, here except for the exporting of the invoice in the two formats, the construction process of the invoice remains near about same,
class ReportBuilder
{
protected:
ReportProduct reportProduct;
public:
virtual void SetHeader( CString & ) = 0;
virtual void SetFooter( CString & ) = 0;
virtual ReportProduct GetReport() = 0;
};
class PDFReportBuilder : ReportBuilder
{
// contains implementaion
};
class ExcelReportBuilder : ReportBuilder
{
// contains implementaion
};
class DirectorReport
{
public:
ReportProduct MakeReport( ReportBuilder & );
};
Now when the Director class object is created and the MakeReport method is called and the parameter of the appropriate type is given, the director orchestrates the calling of the right method of the right type of document needed.
class ReportProduct
{
public:
SetHeader( CString & );
SetFooter( CString & );
MakeReport();
ReportProduct GetReport();
void DisplayReport();
};
There are certain other important ones also, but right now I am running out of steam, maybe will write tomorrow !!
0 comments:
Post a Comment