You're right that writing singletons needs expertise because there are a number of (possibly unsolvable) gotchas that you need to know about to even start using

You're right that writing singletons needs expertise because there are a number of (possibly unsolvable) gotchas that you need to know about to even start using singletons. Take the self-referencing problem: let's say we have a logger singleton (pretty simple, what could possibly go wrong?) And let's say that the logger singleton invokes particular code during its initialization, such as the file I/O code that is also our own and that uses... guess what? a logger! Thus, when the logger class initializes, it will either try to log using an uninitialized object or invoke the initialization recursively depending on whether the singleton is lazy or not. A beginner is normally not aware of this problem when they are writing their singleton class. Another problem is the initialization order: what is initialized first - the logger singleton or the I/O singleton? Turns out, we just have to use lazy initialization. Then the multithreading comes on the scene. So you have to make a thread safe lazy singleton. But that implies additional cost on every call for the singleton. I don't know... Singletons are a mess.