Easy-to-follow video tutorials help you learn software, creative, and business skills.Become a member
I'm going to go through two design patterns and illustrate them as simply as possible, one with code and one without. So you both see an implementation of one, and you get the general idea that this same Design Pattern could be done in multiple programming languages. But it's always the idea, the approach, that matters. Now first up is the Singleton Design Pattern and here's the problem it's designed to solve. We create a class, and we know the classes can be instantiated once or twice or a thousand times, but what if you only want one object of that class.
What if you want to restrict this. In fact, you need there to be only one object of this class? What if this one object needs to represent the currently running application or perhaps the current display and having more than one instantiated object just doesn't make sense and could even lead to problems with the application. There is actually quite a lot of situations where there should only be one object of a particular class. Now this might first sound a little like an Abstract Class, but remember an Abstract Class isn't allowed to be instantiated at all.
So, if we have only one, well, you might first think why don't we just not create more than one? And you could do that, but it's not really enforcing anything, you can't guarantee that behavior. So instead, we can use the Singleton Design Pattern. With the Singleton Design Pattern we ensure that a class only has one instance, and we provide just one way to get to it. Meaning, we don't want to have to write code to instantiate the Singleton, we want to assume that it always exists, there is always one of them, and we just want to be able to ask for it from any other point of the program and get it.
Now, how this is implemented can vary across languages, but what I am going to demonstrate is the classic technique as used in Java. So first we create a class. It's a regular public class. I've called it MySingleton. And this class can contain methods and instance variables and all the normal stuff, there is nothing different about it yet. But because there's nothing different, this class could be instantiated a thousand times, and we need that not to be true. So we actually add a constructor, and I mark it as private.
And what this means is nobody can actually instantiate the class from outside, nobody can just say they want to create a new MySingleton object. However, that doesn't really solve our problem that we need there to be one of them. We just can't create it from the outside. So, how does this object actually come into being? Well, I have two things to do here. What I am first going to do is create a static variable in this class that holds a placeholder to a singleton object, I've called it __me and set it equal to null.
This just means a variable that can hold a singleton object, and there is nothing in it right now. And then we create a new method, and this is the important part of the Singleton Design Pattern. We could call this method anything we wanted to, getInstance is pretty common. And it's a static method, meaning it's called on the class itself. We don't have to have an instance of this class yet. The first thing it asks is do I exist? Is there anything in that __me variable, if it's null then instantiate a new MySingleton object.
Now we're allowed to do that from inside this class, because we marked that constructor as private, which means this class is allowed to call it but nobody else is. And then after the if statement, we'll return that object. And what this means is that it's the getInstance static method of the MySingleton class that is the important way to get to this singleton object. We are actually using a technique here called lazy instantiation, which means that until someone asks for this object it doesn't exist. But when they ask for it, we'll look for it.
If it doesn't exist, we create it, we store a reference to it so that when the next person asks it's already there. So the code that I've just added is all we need, and we've completely turned this into a singleton. As far as anyone else is concerned, there is only one of these. There'll always be one of these. Now the way we would ask for it in another part of the application is just by saying MySingleton.getInstance. That will call that method, check to see if the object exists, if it doesn't, it will be instantiated once and then returned.
If it does exist, it will just be returned. We can then start using the methods of that singleton. In fact, you could really combine this and just call it directly and anywhere else in the application can use this method to get to it. And that is the Singleton Design Pattern. It might seem a little convoluted, but bear in mind it's just a few lines of code, and this works very well. There'll never be any more than one of these objects that's accessible from anywhere in the application without ever having to manually instantiate it.
Get unlimited access to all courses for just $25/month.Become a member
82 Video lessons · 101747 Viewers
61 Video lessons · 88508 Viewers
71 Video lessons · 72321 Viewers
56 Video lessons · 104034 Viewers
Access exercise files from a button right under the course name.
Search within course videos and transcripts, and jump right to the results.
Remove icons showing you already watched videos if you want to start over.
Make the video wide, narrow, full-screen, or pop the player out of the page into its own window.
Click on text in the transcript to jump to that spot in the video. As the video plays, the relevant spot in the transcript will be highlighted.
Your file was successfully uploaded.