All language subtitles for 004 The Singleton (Anti) Pattern_en

So let's take a look now at the notorious singleton pattern or anti pattern, depending on who you ask.

So the idea of the singleton pattern is that you have some sort of object that you only wants to exist

once you only ever wanted to load up once, such as an audio player, an ambient audio player.

You might want this to work across scenes.

So you want there to be one and you want to be able to crossfade audio.

There's only one speaker system in your computer, so it makes sense.

There's only one audio kind of central audio player and that is responsible for cross fighting between

all the different audio in your game.

So if you were to make that decision, then you might decide that if we go and find our Singleton's

code here under patterns and we look at the simple audio player, you might decide that you want the

class to be responsible for making sure that there is only ever one instance here.

And here's how it's usually done in language like C-sharp or even Java, or sometimes C++, too.

The idea is that you create a static instance of the class itself within the class, so you have something

like the ambient audio player class, which has its Crossfade new music method, for example.

That's basically what we want it to be able to do.

But in order to make sure that we only ever get one of these instantiated, we add a private static

member that points to itself.

So this is typically the instance started off as no.

You then have a public static getter to get hold of the instance.

So in another class, you would be able to use it simply by typing something like ambient audio player

dot jet instance.

And you can see that simply goes ahead and would get the instance.

Now, what does that do?

Well, first of all, it checks whether we've already created an instance before.

If we've already created instance, we just go ahead and return that one.

And if we haven't created instance, it goes ahead and creates the instance.

And now, just to make sure that nobody else is going to create a second instance of the ambient audio

player anywhere in your code, you then make the default constructor private.

So that means that no one else outside of this class can go and construct this class.

So taken together, this allows us to instantiate a single instance of the class, make sure nobody

else does it and give us away from anywhere in our code base to access this instance.

Now stop me if you have spotted an issue.

Well, it's basically global state.

So why is it any better than using global state?

Said Statics, a global state.

We've got this static instance of that variable.

We've got a way of accessing it from anywhere.

Isn't it just global state?

Well, a few things make it better for a start.

Singleton means that we don't pollute any namespaces.

This isn't so much a problem with static.

Statics already solve that problem.

Statics don't pollute the namespace, but if you had other languages that you're using like C++, then

you can pollute the global namespace there with global variables and singletons.

Wouldn't it provides encapsulation so you don't have to access these static variables directly.

You can do it through a public interface that manages the state of a class again.

Statics can do the same thing.

You can have private static and you can have public static accesses, and you would essentially get

the same thing without having to create an instance of the class at all.

However, the final point is sort of useful is that it allows us to have lazy initialization.

So if you didn't want this object to be in initialized until we needed it, then it does allow us to

do that.

But basically, it's a not much better than global state, and this is why people see it as being a

bit of an anti-party.

So let's dig in a little bit more into why it's bad.

So it's still a global state.

It can be accessed from anywhere, so it can lead to that spaghetti code situation where you don't know

who is dependent on this code.

It's not immediately obvious we break the rule of three that you can only do one thing because suddenly

this class is responsible for making sure it's instantiated only once, as well as its usual routine

of just doing its job.

But in unity, we often have recourse to want to do something like this because we ultimately can't

write any code that has a larger scope than the scene.

Everything has to reside in mono behaviors.

So we often want those behaviors to travel between scenes with us.

Now, how could we do this in a mono behavior?

Because at the moment we've seen how we can do this just using pure C-sharp classes.

If we want to do this with a minor behavior, this is going to be a challenge.

So imagine that we had a class that looked very similar to the one that we had previously, except this

time it's a mono behavior.

And you can go and get the state of the code linked against this lecture to play around with this,

if you like.

And the first part of this I've already done for you, which is I've said that we on a week we mark

this object as do not destroy on load.

You may also need to do something else on a week in order to ensure that this mode of behavior is instantiated

only once.

Take your inspiration from the way we are using statics and that instance variable to see if you can

achieve something similar with a mono behavior.

And if we get more than one minor behavior in the scene at a time, you can destroy the one that we

don't want.

VIDEO And go.

OK.

Let's head back in to visual studio code.

We're going to go to this ambient audio player behaviour, and what we're going to do here is we're

going to essentially look at whether we are the chosen one when we enter a week and the way we're going

to do that is by having a private static instance.

So going to have a private variable of type ambient audio player behavior and it is going to be called

the instance, and I've forgotten this needs to be static as well.

Because we want it to be shared between all instances of the class.

And it's going to be set to null by default.

Now when we awake for the first time in the first scene, we load that instance is going to be null.

So we'll say if the instance is null, we're going to want to set the instance equal to this and we're

going to want to set don't destroy, unload as well.

However, if this is not the case and so else, we have an instance already and we are not at that instance.

So we need to make this not an else, but an else.

If the instance?

Is not equal to this, then we need to destroy ourselves and probably the game object that we're on.

So we're going to call destroy game object like so so now the audio player will make sure that there

is only one of it hanging around at a given time and we can test this out.

In our scene example.

We had this singleton example with the audio player behavior and we've got a reload, a script which

will reload the scene when you hit Ah.

So if we go ahead and hit play now, then you can see we've got a singleton example.

Here is under the Don't Destroy and load section and we can go ahead and hit all and the scene reloads.

But we don't get a new singleton example being created here.

It will stick to that initial one, and we probably do get one created very briefly, but it gets destroyed

on awake.

So that's the singleton pattern, as it's usually used in a nutshell.

As I say, try not to use it as much as possible because I do think it violates some of our best coding

practices.

Sometimes it's unavoidable.

But if for those cases, I have got a solution that, in my opinion, is slightly neater and we're going

to see that in the next lecture.

I'll see that.