1- Take a programmer who's tied to an IoC container and DI as a way of life, along with anti-singleton, and interface everything.

2- Introduce him or her to a dynamic language. Specifically focusing on testability without DI, interfaces and fear of singletons and statics.

3- Watch as he or she either:

a - accepts the fundamental truth that all that crap in a static language doesn't add value outside of freeing you from the language

b - refuses to believe that what you are doing can even be classified as programming

This is equally entertaining to do to either a very "experienced" (doing the same thing for the last 10 years) programmer, or someone who's just discovered mocking and mocks everything.

You can tell a lot about a Java or C# programmer by how readily he or she accepts this shift (which isn't to say they magically switch over to a dynamic language, but they should recognize that all that stuff a static language demands of us is really a limitation of said languages).

1) Singletons do make sense when they represent a true physical singleton - for example, you only want one piece of code drawing directly to the screen, the Window Manager, which should indeed be a singleton.

2) Most of your problems stem from the us of GetInstance() not from the use of the Singleton pattern in and of itself. For example, without GetInstance(), the other way to get a reference to the Singleton object is to pass it in to the object that is going to use it. This indicates the dependency in the client class's interface, and also makes mocking out the Singleton for test purposes a real possibility.

I’m Adam, and i’m a recovering Singleton addict.

Posted by aschepis on May 2, 2011

My name is Adam, and i’m a recovering Singleton addict. There, i’ve said it. I used to use singletons all the time because they make doing some things, like sharing state globally, incredibly convenient. My code was littered with XYZManager classes. The defining trait of these classes was the static GetInstance() method that magically enabled me to get access to that object and its state wherever I wanted!! What a great idea, right?

What a mess! I learned over time that the cost of changing one of these things, or the cost of doing a major refactor was really high in terms of code change. And to make things worse, because my classes’ dependencies were hidden in implementation and weren’t transparent in the interfaces it was impossible to write real unit tests. This made doing a big refactor even less attractive.

So over the years, through work in the industry and coding on my own I’ve come to the conclusion that the singleton sucks, and that there are very few places where they are actually appropriate (logging comes to mind as one acceptable place). The fact of the matter is that most of the places I see singletons used in software they are actually just an enable for developer laziness.

So here is my off the cuff list of why singletons suck. Feel free to comment and add your own reasons (or counterpoints)

Singletons hide your dependencies. This makes code harder to understand Singletons make unit testing difficult. It’s hard to mock out a global object that you can’t inject into a class Singletons reduce reusability. If i’m writing a class that utilizes a singleton because my application will only ever use one then i’m limiting myself because I can’t use that library to write test tools that may want to simulate how many of these object (for instance, many users) interact with a system. Singletons reduce scalability. A single, global object? Sounds like a source of contention to me. Singletons are not good object oriented design, they are lazy!

The most beautiful Singleton code I've seen in C++ is:

  class GrSubsys
  {
  public:
    GrSubsys();
    ~GrSubsys();
  };
  extern GrSubsys* gGrSubsys;

  //-------------------------------------------------------
  void
  App_Startup()
  {
    // initialize graphics subsystem.
    new GrSubsys;
  }

  //-------------------------------------------------------
  void
  App_Shutdown()
  {
    // shutdown the graphics subsystem.
    delete gGrSubsys;
  }

  //-------------------------------------------------------
  int
  main()
  {
    // startup the engine.
    AppStartup();

    // enter the per-frame application loop.
    while ( AppFrame() )
    {
    }

    // shutdown the engine.
    AppShutdown();

    return 0;
  } 
     

For example, we use at work DEJA Insight Profiler, and you can directly put profile probes (C++) with DEJA_CONTEXT("SomeFunction") - it's using RAII to mark start/end of the probe. But the point is there is no explicit call to DEJA_INIT, or DEJA_CLOSE, etc. But this only works if the DEJA main application is loaded.

http://zmotula.tumblr.com/post/1390385240

There’s also a blog post called Singletons Are Pathological Liars by Miško Hevery, which is very well thought-out and contains links to other related topic:

http://misko.hevery.com/2008/08/17/singletons-are-pathologic...

Hope that helps somebody, reading Hevery’s articles was a huge eye-opener for me.

Hmm, so perhaps that says something more about OO than "singleton style"?