Lecture thumbnail 0:04 / 2:44 In this section of the course.
We’re going to take a look at the much hated design pattern, which is the singleton.
And 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 Patterns book, its authors 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 Erich Gamma, one of the authors of the original Design Patterns book,
basically says it all.
He says that when discussing which patterns to drop, we found that we still love them all.
Not really.
I’m in favor of dropping the singleton.
Its use is almost always a design smell and I have to agree here that the raw use of a singleton 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 it a zillion times, especially when you’re testing code.
You don’t really want to start reading the database a zillion times in your tests 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 of 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 instantiated more than once.
Stop Play Play Play Play Play Play Start Play information alert