Implementing a Well behaved Singleton - 2

In the second part of this series, Lets look at a simple singleton implementation and see how these questions affect the implementation.

class FooSingleton

{
   public :
       FooSingleton(void);
       ~FooSingleton(void);

       static FooSingleton* GetFooObj(void);

   private :
      int m_var;

};


static FooSingleton g_fooSingleton;

FooSingleton*
FooSingleton::GetFooObj(void)
{
    return(&g_fooSingleton);
}

The problems with this code
(a) There is no guarantee that User of the class cannot create another instance of the class. So technically this is not a singleton.
(b) User can derive from this class. Usually not a good idea for singletons.
(c) Single instance is implemented using file static object. The sequence of static objects is decided by the compiler. Hence if other static objects depend on Singleton instance of FooSingleton, you have a problem. It may happen that g_fooSingleton is not initialzed yet.

Not a well behaved implementation.

Lets see how to improve on this. First lets make the constructor of the FooSingleton private. This will take care of (a) and (b). Problem however is then you cannot create file static 'g_fooSingleton'. It has to be implemented differently.

class FooSingleton
{
   public:
       ~FooSingleton(void);

       static FooSingleton* GetFooObj(void);

   private :
       FooSingleton(void);

   private :
      int m_var;
      static FooSingleton* m_pFoo;

};


FooSingleton* FooSingleton::m_pFoo= NULL;


FooSingleton*
FooSingleton::GetFooObj(void)
{
    if( m_pFoo == NULL)
           m_pFoo = new FooSingleton();

    return(m_pFoo);
}

First call to GetFooObj will create the Singleton instance, subsequence calls will return the same instance. There are still problems with this implementation.
1. GetFooObj is returning a pointer. What happens if user deletes this pointer by mistake ? The FooSinglton object will NOT know that the pointer is already deleted.
2. Exactly this singleton instance of FooSingleton is going to be destroyed ? Since m_pFoo is a pointer, its destructor will not get called automatically. That could be a problem.

The User (developer) has to manange the destruction of Singleton object and he needs to be really careful in using the class (.e.g don't keep copy of the pointer to FooSingleton, don't delete the pointer to FooSingleton etc). Not a well behaved implementation.

How to improve on this is part of next installment of this series :-)

Implementing a Well behaved Singleton - 1

Singleton is one of the simplest design patterns. It also the one most abused. I have seen developers replace a global variable with a signleton object and argue that since its a design pattern, its good without really looking at the intent of the pattern and the effects.

What do i mean by a Well Behaved Singleton ? A well behaved Singleton will have following characteristics.

1. Construction is trasparent to the user(at start of program or on demand).
2. If construction of the singleton depends on some other object being initialized first, then the implementation should ensure that constructor sequence is correct under any circumstances.
3. Destruction is trasparent to the user.
4. If some other object (esp. destruction of some other object) depends on Singleton, timing and sequence of destuction of Singleton should be correct in any circumstances.
5. Single instance is ensured by the implementation. It should be impossible to create a second instance. If the user tries to create a second instance, the implementation should give an error (e.g compilation error, assertion failure etc)
6. All assumptions are made explicit.

Assuming that you understand intent of pattern and want to implement a singleton, there are many ways to achieve it, depending on your needs. First Lets look at major considerations for how to implement a Singleton.

1. Do you anticipate a need to create a derived class which is also a singleton ?
2. Does the initialization of a Singleton object depend on some other object being already initialized ?
3. Does some other object (e.g. other singleton) depend of Singleton object being initialized first ?
4. Does the destruction of a Singleton object depends on existance of some other object ?
5. How Are you ensuring destruction of Singleton ?

In this series I plan to look at some ways of implementing Singleton, look at pros/cons of them and see how well behaved they are.

Notion of Repeatable processes

From the recent discussion on PragmaticProgrammer Mailing List:

(From Mail from Andrew Hunt)

Here's a side question for ya'll on the notion of repeatable process: I want a formula of how to make a hit movie. Perfectly repeatable, with no consideration of the talent involved. Just turn the crank and rely on the process to work.

Now replace the 'hit movie' with Software Product/Project. I never seen the concept explained with such a simple and thought provocating metaphor.

Craft Of Programming and Mentors

One thing I learned from my experiences in Software Development is 'Software Development' is not 'Computer Science'. Its not a science and its not fully an art also. Sometime back I read an article where the author called it 'Craft'. I really liked the idea. Indeed, programming is a craft and a Good Software Developer is like a Master Craftsman.

As Craftsman you learn the tricks of the trade by doing it many times, mostly under the watchful eye of Master. There are really few Craftsman so gifted that they can learn it on their own. It means early years of Software Developer are very important. Those early years define if you become a average developer, a good developer or a Great Developer. If you are working with a Master Programming Craftsman, you will learn much just by observing how he works. If the Master Programming Craftsman is also a Good Teacher and Mentor, Then You are Very Very Fortunate.

I am fortunate because my initial years were spent with Master Programmers like T.N. Umamaheshwaran, Abhay Tarnekar, Pravin Waghmare, KK George in MSDCAD, Telco. I learned a lot in 1 year at Telco. Afterwards, I learned from the books of other Masters like Brian W. Kernighan, Rob Pike, GoF, Robert Martin, Martin Fowler, Steve McConnell, Herb Sutter, James O. Coplien, and many others.

Here is a my list of Good Books from some these masters which shaped my ideas of software development.

1. C++ Gems series
2. Code Complete
3. The Practice of Programming
4. GoF Design Patterns Book
5. Advanced C++ Programming Styles and Idioms
6. Robert Martin's articles on Design Principles.

Trust your developers (employees) and treat them as Responsible Adults

This is the first lesson I learned when I become a Manager of a software development team. 'Treat your Developers as Responsible Adults and Trust Them'. This simple advice, gave a me big advantage namely Trust and Support of the Development Team. 

Sometimes big benefits start with a simple ideas. Let me give an example to clarify my point.

Scenerio : An Important release of your project/product is coming up and a developer comes to you and asks for a 2 day vacation (leave). What will you do ?

The most common reaction in companies/project groups is to DENY the request. Manager will ask the developer to postpone it or even go to extremes like accusing him of 'not being a team player'.

Saying 'no' is a REALLY BAD IDEA. Does your team know the importance of the release ? Do you trust the judgement of the team members ? Do you treat them as kids to be disciplined or as responsible adults ? If you are treatng them as responsible adults and if the developer knows the importance of release and still asking for vacation, then it must be that important for him. So Don't be a PHB AND say that 'YES, you can take the vacation'.

If my release is stopped because of unavailability of one developer, then actually I am a BAD MANAGER. In Software, people do change companies. So if only one guy knows some part of the project and if he leaves for some reason, I (the Manager) am in major trouble. Its my responsibility to ensure that doesnot happen. I should not pass the blame to the team.

Treating developers as 'responsible adults' has lot of side benefits. You become part of THE TEAM. Lot of times, its team versus Manager (you). Now its Team (you + developers+qa) versus the product/project/deadline/problem. Now you have much better chance of Winning.

You respect the team members for their abilities and they respect you for your abilities. The Team is much more confident to suggest unconventional and innovative solutions to problems at hand.

If I ask the team members to come on weekend (a rare ocurrance in my teams), the team comes in without any complaints. Most of the time I don't even have to ask. If they feel its neccessary work on weekend for some reason, they will come on their own.

The team depends on each other expertise, advice is freely sought and given, the team morale and hence productivity is high.

Its real WIN/WIN for everyone...