Global singletons are evil

I’ve read many good blogs recently detailing why global singletons are evil. This thought has been brewing in me a long time. No design pattern is easier for the novice to pick up and use and misuse as the singleton. The (mis)perceived elegance of hiding global variables in a singleton is truly an evil thing. Sure Singletons are better than have all static access methods, and sure having all static access methods is better than having global variables and routines for the same thing. But the lesser of two evils (or three) is still evil. The desire to constrain a class to one instance is a good one when appropriate. I prefer the thought that singletons should return a valid object pointer on the first call and null on subsequent calls. This is what you would expect a class that can only have one to do. Using this method you get one instance that you use in the same manner as normal class instances. There should be a support group for people who like to hide globals in singleton’s – for all their handwaiving they aren’t fooling anyone;)

I have seen project where just about every class is a global singleton ….. how very (un)object oriented. Even Vlisside’s jumps on the band wagon in Pattern Hatching bringing up his regrets about this pattern. One simple change can clean it up so nicely – only return the valid instance ONCE.

One thought on “Global singletons are evil

  1. codematrix

    It’s not that singletons themselves are bad but the GOF design pattern is. The main argument that is valid is that the GOF design pattern doesn’t lend itself in regards to testing, especially if tests are run in parallel. It all comes down to how singletons are created/obtained which is the crux of the problem.

    Using a single instance of an class is a valid construct as long as you apply the following means in code:

    1. Make sure the class that will be used as a singleton implements an interface. This allows stubs or mocks to be implemented using the same interface

    2. Make sure that the Singleton is thread-safe if necessary. That’s a given.

    3. The singleton should be simple in nature and not overly complicated.

    4. During the RUNTIME of you application, where singletons need to be passed to a given object, use a class factory that builds the depending object and have the class factory pass the global singleton instance to the depending object that requires it.

    5. During TESTING and to ensure deterministic behavior, create the singleton class as separate instance as either the actual class itself (copy) or a stub/mock that implements its behavior and pass it as is to the object that requires it. Don’t USE the class factor that creates that object under test that needs the signleton during test as it will pass the global singleton instance, which defeats the purpose. But rather, create the class under test exactly how the class factory would have created but with the added benefit of substituding the global singleton with a copy or stub/mock.

    We’ve used Singletons in our solutions with a great deal of success that are not tightly bound, extensible, replaceable and are testable, ensuring deterministic behavior in parallel test run streams.



Leave a Reply