We're going to cover what it is when you should use it when you shouldn't use it, and we're going to go over some code that is not using this English and design pattern.

And then we're going to re factor to use the singleton design pattern like it should be before we start re factor in any code to use the singleton pattern, let's first talk about what it is.

In essence, the singleton pattern is just a way of creating a single object that has shared amongst a bunch of different resource is throughout your application without having to recreate that object or lose any of the information inside of it.

All of the state for that object, the variables, methods all those our shared among all these different other objects that are using it.

And there's there's one source of information for this object, and there's only ever a single type of this object created.

This is why it is called a singleton, because your application will only and can only have one type of this object in Stan.

She ate it at a time, and all places that use this object share that one single instance of the object.

So as you can see from this example here, we have our singleton in the middle, which is our one single object.

And all of our other objects A, B, C and D are all using that one instance of that shared object that is going to have all the state for that singleton inside of it, and they don't create their own instance at that object each time.

And that's really all the singleton pattern is is a way to create a single object that have shared amongst the buster different parts, your application.

But this can lead to some problems with creating global variables, Since the Singleton's are essentially global to your entire application, having a single object that is global to your application and control so much of your application could be incredibly hard to test, since you need tohave that single object in order to test anything, and it can create a bunch of coupling between the different parts.

Your application where all of your application relies on this singleton object, so it becomes very hard to change the re factor that object, since all the rest of your application is so dependent on it.

Lastly, you can run into what's called the race condition, where changing things inside of this singleton in different parts your application to the same time can cause data to get overwritten or not read correctly because they're all trying to access the exact same information at the same exact time.

Because of these downsides, some people said that you should never use the singleton design pattern in any of your applications.

But I believe that there are certain uses for the singleton design pattern where it could become better than using a non singleton design pattern.

In those cases where you have certain sets of small information that needs to be shared throughout all of your application.

Using a singleton pattern in orderto get all that information into one coherent place can be easier to work with than having to create a bunch of different classes and making sure that those classes save the information properly and so on.

So let's dive into an example of some code that does not use the singleton pattern, which I believe should use a singleton pattern and then what's actually implement the singleton design pattern in that coat.

Here I have visual studio code open on the left with all the code for this project and on the right.

I just have the console so we can view the output of our code before we get started any further.

I do want to say if you are not familiar with the module system for exporting and importing modules in JavaScript, make sure to check out my export import module of video, which will be linked in the cards and the description blow, because we're going to be using that heavily in this example.

To start with, we have this fancy longer class which all it does as you create a new one, and it creates an empty array of logs, which are all the things that you log inside of it.

It has a function for logging out any message.

It'll add that log to this log array that we created, and it also log it to the council so that we can see it and then lastly, we have a method just to print out the number of logs that we have saved inside of our class so far.

And then we're exporting that.

So we can use this fancy longer module anywhere in our application and we have to use is where we want to use it.

We have this first use J s class, which we're going to use inside of this implementation class which we're going to implement here soon.

We have a second use, which is exactly the same as the 1st 1 But it's just a second use case.

And then finally, we have our index dot jazz file, which is what's actually being run over here inside of our browser for our council logs.

And all this does is take our first and cycle implementation and it's going to call both of those methods that we implement.

So let's start by implementing this first use.

As you can see, we've already imported are longer and created a new instances.

It So what side of here?

What's log?

The number of mugs that we have So we could just say friend, Lord comes, we should know that this should be zero and then we just want to log.

Somethingto are longer.

So let's just say we're gonna log first file so that we know over in the first file.

And then as soon as we're done that we're going to print out the log count again and we're gonna copy that because we're gonna do the exact same thing in our second use case file here.

But it said we're going to print second file instead of first file.

And as you can see, our first file has already run and you see it says zero logs printed out first pile, and now one longs.

So now if we save this file, we'll see that both of our functions will run.

But you'll see that it runs zero Long's first file, and we have one log in the longer.

And then it goes back to having zero wogs inside of our longer and then print out the second file and says that we have one log, and that's because in each of these files we're creating a new instance of this fancy longer, so we don't have all that shared information from the previous instance of the longer because we're creating a new one every time that we import it and use it.

This is a great use case for where we're going to want to use the Singleton pattern, since we want all uses of our fancy longer class toe actually have the number of logs in it that we've logged so far.

So let's go back to our fancy longer here and implement this as if it was a singleton.

The first thing we want to do is we don't actually want to export the class itself because we never want to actually use the class.

We just want to use a single instance of this class.

So that's the entire idea of the singleton pattern.

And since we only want a single instance of this class, we want to make sure that we only ever create one single instance in our constructor.

So in order to do that, we could just use a static variable on our fancy longer so we could say fancy logger dot instance, which in this case is just a variable that we're creating, and we want this toe always be a single instance of the fancy longer and no other instance could overwrite this.

So if this instance is no, that means that we have not actually created a fancy longer yet, so we want to create a new one.

So we're going to extend.

She ate this dot logs to be an empty array, and then we're going to take that instance variable, that we're going to set that to this, which is the new fancy, longer instance we created.

So now every single time that we run this constructor here, if there's no instance created yet, so if it's the very first time we're going to initialize it and set our instance to whatever we're creating, then the second time that we run this, it's just going to return down here.

We're just gonna say, return fancy longer dot instance.

And essentially, what this is saying is that we always want to return that single instance every single time from our constructor instead of returning a bunch of different instances every time and then down here we want to do is we want to create that fancy longer instance before we export it so we could just create a variable, just call new fancy longer and now we have an actual instance of R.

Singleton.

But to be able to make sure that nobody can actually mess with this.

We're going to use a method called object dot freeze, which will pretty much prevent this object from being changed in any way.

We're just passing are longer here.

So now this longer class cannot have any new method or variables added onto it or removed from it by our code.

And then lastly, we just want to export in the default that Logar.

So now we're actually exporting an instance of our longer instead of a class.

So instead of all of our use cases here, we know that we're actually importing a instance instead of the class so we can completely remove this line.

We're creating a new version of the class and we could do the same thing in here.

Remove this line.

Now, if you say that you see that we get zero Long's the first time that we use it.

It prints out first file, and then it has one long.

And when we get into that second use case in this file here, even though we're importing, the longer this import is just importing the exact same instance.

So we still have that one log being persisted.

We print out our log, and now we have two logs inside of our fancy longer.

And that's because we're using one single instance, as I mentioned before.

And that's all there is to using the Singleton design pattern.

If you guys did enjoy this video, make sure to check on my other design pattern videos and JavaScript videos, which are going to be linked over here and subscribe to the channel.

If you enjoyed the content from more content just like this in the future, thank you guys very much for watching and have a good day.