In this section of the course we're going to take a look at the much hated design pattern which is the
single thing that we're going to discuss whether it's really as bad as people say it is now about 15
years after the publication of the original design Pancho's book it's all there is actually met to discuss
design patterns and they noted that they would keep all of the patterns as they are with perhaps the
exception of the singleton and the quote you see here from Eric gammer one of the authors of the Original
Design Patterns book basically says it all.
He says that when discussing which patterns to draw up we found the we still love them all.
Not really I'm in favor of dropping the singleton.
It's use is almost always and design special and I have to agree here that the rural use of a single
word and is quite often a design smell particularly in systems which are theoretically supposed to be
extensible and testable and all the rest of it.
But we're going to see what the problems with the singleton are and how we can overcome them.
So the motivation for using a singleton is fairly obvious for some components in our system it only
really makes sense to have one instance in the system for example let's suppose that you have an object
which accesses a database maybe it loads up the database in its constructor into memory and then gives
out information about the contents of that database once it's loaded up you don't really want more than
one instance of it because there is no point.
You read the database once you don't want to read a zillion times especially when you're testing code
you don't really want to start reading the databases a million times in your test because tests by definition
are supposed to be numerous.
Another example is the object factory.
Let's suppose you have a separate factory component which actually just creates some components do you
really want more than one instance of it.
Well not really because a factory isn't supposed to have any state.
So we're looking at situations for example where the constructor call for a particular object is particularly
expensive and you only really want to have that constructor call being done once and then subsequently
once you call the constructor once you construct that singleton object you want to provide everyone
every single consumer with the same instance of that object that instance that you've just constructed.
And you also want to prevent your clients from making any additional copies of that object.
And of course there are other concerns on top of that.
For example you want the object to be lazy you want some sort of thread safety so there is no way in
which case the constructor is actually executed twice and introduces some sort of race condition you
want to avoid all of this.
And that's what a correct implementation of singleton is all about.
So the singleton is essentially just a component which is instantiated only once and which tries to
resist the idea of it being insensate and more than once.