Template based Factory Method January 9, 2007

Factory method pattern is similar to Abstract factory, the major difference being that the former requires sub-classing to create the product objects where as the later does not require. There may be a problem scenario with Factory Method, as having a sub-class for each product may not be desirable. This may be over come by having a parameterized factory method class implementation.

// Product Family
class CAbstractProduct
{
public:
CAbstractProduct();
virtual ~CAbstractProduct();
virtual bool Init() = 0; //
};

// ‘Factory Method’
class CFactory
{
public:
virtual CAbstractProduct* Create() = 0;
};

////////////////////////////////////////////////////////////
template <class TheProduct>
class CTemplateFactory : public CFactory
{
public:
CAbstractProduct * Create();
};

template <class TheProduct>
CAbstractProduct * CTemplateCreator
::Create()
{
CAbstractProduct *pClass = new TheProduct;
pClass->Init(); // Initialization function
return pClass;
}

Here is an example for the above implementation:

class MyClass : public CAbstractClass
{
public:
MyClass();
virtual ~MyClass();

bool Init(); //optional

private:
int m_nSomeVal;
};

MyClass::MyClass()
{
m_nSomeVal = 0;
}

MyClass::~MyClass() { }

// Initialize the object
bool MyClass::Init()
{
m_nSomeVal = 20;
printf(”I m been intiallized to %d!\n”, m_nSomeVal);
return true;
}

int main(int argc, char* argv[])
{
CTemplateCreator myClassCteator;
CAbstractClass *pMyClass = myClassCteator.Create();
return 0;
}

CTemplateFactory
It is not necessary to always derive CTemplateFactory from an AbstractFactory, but doing so give you a freedom to extend the Factory chain later.

Killing a singleton January 8, 2007

I am reading “Pattern Hatching” by John Vlissides (http://www.research.ibm.com/designpatterns/pubs/ph-jun96.txt). I have come across the Singleton Pattern. The way to use a SingletonDestroyer (SD) class to “KILL a Singleton instance” is interesting.

In John’s approach, destructor is made protected so that the user is not allowed to delete the singleton instance explicitly, also as said Singleton class has the responsibility to construct and destruct its instance. For this reason a separate class SD is introduced, which is a friend of class Singleton. Class Singleton also has a static member of SD. So as the SD’s instance goes out of scope, it deletes the pointer of Singleton assigned to it. SD has public constructor and a setter function to set the Singleton pointer.

class SingletonDestroyer {
public:
SingletonDestroyer(Singleton* s= 0) { _singleton = s; }
~SingletonDestroyer() { delete _singleton; }

void SetSingleton(Singleton* s) { _singleton = s; }
private:
Singleton* _singleton;
};

class Singleton {
public:
static Singleton* Instance();
protected:
Singleton() { }

friend class SingletonDestroyer;
virtual ~Singleton() { }
private:
static Singleton* _instance;
static SingletonDestroyer _destroyer;
};

Having a public SD constructor give a chance to user to create the SD object explicitly, such as:

Singleton *pSingleton = Singleton::Instance();
SingetonDestroyer explicitSingletonDestroyer(pSingleton);

So the basic purpose of making the destructor of Singleton protected is defeated.

I have made a minor change in John’s approach to rectify this problem. Class SD is made the protected inner class of class MySingleton. This prevents the user from creating an instance of SD class explicitly and thus restricting the user to delete the Singleton pointer knowingly or unknowingly.

class CMySingleton
{
protected:
class SingletonDestroyer // Inner Class
{
public:
SingletonDestroyer () {}
~SingletonDestroyer () {
delete _pInstance; // deleting the singleton instance
}
private:
// Prevent users from making copies of a
// Destroyer to avoid double deletion:
SingletonDestroyer(const SingletonDestroyer&);
void operator=(const SingletonDestroyer&);
};

friend class SingletonDestroyer;
protected:
CMySingleton();
virtual ~CMySingleton();
public:
static CMySingleton* GetInstance ();
void DoSomething();
protected: //members
static CMySingleton *_pInstance;
static SingletonDestroyer _destroyer;
int _nSomeVal;
};

It still doesn’t help you if you need to delete your singleton *before* the end of the program.

Singletonitis December 17, 2006

My colleagues say that I am infected from “Singletonitis”. It is an addiction to Singleton pattern. Singleton pattern allows only a single instance of a class with a global access. Now my addiction is not on its over use in code, but because of lot of preaching to my team mates about singletons…

It may not always be necessary to have singletons if the class in question has insignificant memory, rather stick passing the object as the reference (argument) to the functions in such cases. Prefer singletons in places where the object memory size is significant.