Your image seems to be broken...

Singleton isn't always a bad thing otherwise the GoF wouldn't of made a pattern out of it.   There are places where it's appropriate to use, and places where it's not appropriate to use (which will result it one screwing themselves as you so put it, and I certainly agree with that).

Like all things, knowing when to use it and when not to use it is the key.  Your reference to a 'TDD' friendly way of doing static operations is definite option in many cases that people over-look unfortunately.   Perhaps I misread your comment, but the implication that people will get screwed over using singleton when they may be using the pattern correctly seems a bit dooms day to me.  If I read it incorrectly I apologize.

The problem isn't the tool, it's the person using the tool.   That's what needs to be fixed/educated, and no 'tool' in the world, no matter how limiting (or unlimiting) it is will fix that, only instruction and experience will cure that.

Absolutely! (re: knowing better about blindly following something just because it's in the GoF book)

Pingback from  igorbrejc.net » Fresh Catch For January 7th

Defining singleton-like behaviour in StructureMap is so much more easy than creating them anyway. <3 AsSingleton().

I don't understand why anyone would both with all the lazy fudge and borked double-checked locking.

Pingback from  Dew Drop - January 7, 2009 | Alvin Ashcraft's Morning Dew

* spooky whisper *

I see dead kittens.....

okay so I've probably had not enough sleep and too many M&Ms but it was the first thing that came to mind when I saw the image.

I've seen many complaints about Singleton and I've seen many code which leverages Singleton as the last resort to obtain the accessibility of some root nodes. but still, it's not fair to blame Singleton itself.

I agree with Brain, the key point is to evaluate carefully when it's appropriate to use it.

When I need to use a singleton I use a template wrapper similar to the one in the Ace toolkit.   A scrubbed version of the one I use now is included below (even including my original anti-proliferation comments).  Anyway, the main benefits are 1) Standardized interface to accessing instances.  2) Class logic is independent of the singleton feature.  3) Ability to free up the memory if needed before program exit.

The friend functions just give a more convenient usage that reads nicer too.

Instance<Foo>().Bar(); // using Instance friend function

vs

Singleton<Foo>::Instance().Bar();  

/// Can turn ordinary classes with default constructors into Singletons.

/// The proliferation of singletons is discouraged, however where the use

/// is justified, this class will make singletons easier to create and

/// standardize the interface.

///

/// If you want to make sure that only the singleton instance of <T> is

/// created, and that users cannot create their own instances of <T>,

/// do the following to class <T>:

/// (a) Make the constructor of <T> private (or protected)

/// (b) Make Singleton a friend of <T>

/// Here is an example:

/// \code

/// class Foo

///    {

///    friend class Singleton<Foo>;

/// private:

///    Foo () { cout << "foo constructed" << endl; }

///    ~Foo () { cout << "foo destroyed" << endl; }

///    };

/// \endcode  

template <typename T> class Singleton

{

  friend T& Instance<T>();

  friend void InstanceCleanup<T>();

  T mInstance;

  static Singleton<T>*& rpSingleton();

  {

     static Singleton<T>* sp_singleton(0);

     return sp_singleton;

  }

  Singleton()

  {

  }

  static T& Instance()

  {

     Singleton<T>*& rp_singleton(rpSingleton());

     if (0 == rp_singleton)

     {

        rp_singleton = new Singleton<T>;

     }

     return rp_singleton->mInstance;

  }

  static void CleanUp()

  {

     delete rpSingleton();

     rpSingleton() = 0;

  }

};

template <typename T> T& Instance();

{

  return Singleton<T>::Instance();

}

template <typename T> void InstanceCleanup()

{

  Singleton<T>::CleanUp();

}

Appreciate the articles on why the singleton pattern is over used. Just as a side note,  I was recently doing some side work in grails/groovy and had to figure out how to test a service that used static methods (not by choice). Specifically, I had to mock out Thread.startDaemon(). It's rather easy in groovy (not sure you care) but thought it was worth mentioning.

To see the full example go here jlorenzen.blogspot.com/.../groovy-threads-and-metaclass-example.html