Exemplars provide safe models for new designs, implicit checklists of design tasks, warnings of potential mistakes and launching pads for radical new designs. Hence great designers have invested great efforts in studying their precedents. Bach took a six month unpaid leave to study the work and ideas of Buxtehude. Bach proved to be much greater composer but his surpassing excellence came from comprehending and using the techniques of his predecessors and not ignoring them
I argue that great technical designers need to do likewise but that the hurried pace of modern design has discouraged this practice. ... Technical design disciplines eager to produce great designs need to develop accessible bodies of exemplars and knowledgeable critiques of them (page 154-155)
‘Certainly lazy or slack designer can minimize his work by picking an exemplar and just modifying it to fit. By and large, those who just copy do not draw on ancient or remote exemplars but only on those that are most recent and fashionable’ (page 162).
Stream astream=null;The developer was trying to ensure that stream is closed in case of any exception is thrown (or multiple returns). However, there is much simpler way to do achieve the same result. Rememer 'Stream' objects implement IDisposable interface. So you can achieve this same effect simply by
try
{
astream = new FileStream(...)
....
// do some processing on stream
}
catch(...)
{
}
finally()
{
if( astream != null)
{
astream.Close()
}
}
using (astream = new FileStream(...))
{
....
// do some processing on stream
}
class FooSingleton
{
public:
~FooSingleton(void);
static FooSingleton& GetSingleton(void);
private :
FooSingleton(void);
static void DestroySingleton(void);
private :
static FooSingleton* m_pFoo;
int m_var;
};
////////////////////////////////
// In the .cpp file
FooSingleton::m_pFoo = NULL;
FooSingleton::FooSingleton(void)
{
//...
// Code construct foo singleton
::atexit(FooSingleton::DestroySingleton); // THIS IS KEY }
}
FooSingleton&
FooSingleton::GetSingleton(void)
{
if( m_pFoo == NULL)
{
m_pFoo = new FooSingleton;
}
return(*m_pFoo);
}
void
FooSingleton::DestroySingleton(void)
{
delete m_pFoo;
}
class FooSingleton
{
public:
~FooSingleton(void);
static FooSingleton& GetFooObj(void);
private :
FooSingleton(void);
private :
int m_var;
};
FooSingleton&
FooSingleton::GetFooObj(void)
{
static FooSingleton fooObj;
return(fooObj);
}
1. GetFooObj function is now returning a Reference to FooSingleton and not a pointer. So chances of user, copying and deleting this pointer are less.
2. There is no global FooSingleton pointer. The GetFooObj function is now using a function static instance of FooSingleton (fooObj)
1. when fooObj is created on the first call to GetFooObj().
2. Every subsequent calls same instance is returned.
3. Since this is a static object, compiler manages the destruction of the object. User don't have to worry about destructing the singleton.
4. Singleton object creation sequence is now predictable. So if some other global/static object is dependent on existence of FooSingleton instance, GetFooObj() function will create it at appropriate time.
The problems with this codeclass 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); }
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. 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.
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 ?