All right so let's try to summarize all of the things that we've learned about the supposedly evil singleton
design pattern.
So we saw that making a save singleton is generally easy so all you have to do is first of all you have
to hide or delete the ordinary constructor or the copy constructor as well as the copy assignment operator.
And then what you do is you make some sort of static method which returns a reference to a static instance
which you're either keeping as part of the overall type or you just stick it right inside the method
itself.
It doesn't really matter now since C++ 11 we are guaranteed that this kind of initialization is actually
thread safe.
So you're not bound to run into a situation where you're calling the getter for the singleton on two
threads and you inadvertently end up constructing two static objects.
That's simply not going to happen.
Now we saw also that when you have A-type with a hard dependency on a singleton this type becomes very
difficult to test because you cannot substitute a new thing.
Instead of this dependency so generally sort of direct dependency is not a good idea because you cannot
decouple the singleton and supply some sort of fake object instead.
And so you end up effectively with an integration test instead of a unit test.
So instead of directly depending on a singleton you might want to consider it depending on an abstraction.
So for example you take the singleton you extract its interface and then you supply that interface in
the constructor of whatever type actually needs to make use of the singleton so that you can substitute
it later.
And finally we have the kind of industry strength's solution which we looked at which is defining a
singleton lifetime in a dependency injection container and simply using that to initialize your components
instead.