The Alien World

 In my experience, usually as a developer you will never get clear cut project requirements, to an extent that there are no considerable requirements at all. Traditional approach is usually following waterfall model where requirements are captured upfront. Most of the time these requirements are not complete or adequate enough, which later results in extra cost and time.

Requirements are driven by market (, which is directly related to customer needs), but most of the time these requirement are at very high level, 35000 ft. above the ground. Sales and marking folks have a vague idea of customer requirements. Business analyst or product managers talks mostly in theories. No one is to be blamed for this because they don’t have a clear idea of what a customer wants. In certain cases not even customer has that.

From a developer’s perspective it’s a lot of frustration to work on something without any clear requirements. Many of the times the untold requirements are discovered during late stages of testing or customer or sales previews. These are then basically considered as change requests or defects.

All these can be handled in the early phases of development itself by adopting a prototype based development model. Agile or XP methodologies are also based on prototype based development model. It may not be necessary to adopt agile methodology as it is for development process. Variations to agile can always be considered based on the project needs.

Adopting prototype based development model is easy if you have high level requirements. Problem is where to start from? It is sometimes very difficult to get the starting point, but that is also solved even if you have slightest idea of what you are working on. Most of the time, in my observation, once you start realizing your ideas, you unblock the flow of more ideas. The picture becomes clearer, and you start adding more colors to it. 

Once you reach some logical point in your prototype, show it to your stake holders. Their feedback is important. Like you they also get more ideas after looking at the prototype.

Always be aware not to spend too much time on then. Remember one thing, prototype is developed to make your requirements clearer or exploring the technology. It is not the actual application that you are going to ship to customer.

Happy prototyping!!!

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.