Example: the singleton pattern
Video: Example: the singleton patternI'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.
- Additional resources
Viewers: in countries Watching now:
Most modern programming languages, such as Java, C#, Ruby, and Python, are object-oriented languages, which help group individual bits of code into a complex and coherent application. However, object-orientation itself is not a language; it's simply a set of ideas and concepts.
Let Simon Allardice introduce you to the terms—words like abstraction, inheritance, polymorphism, subclass—and guide you through defining your requirements and identifying use cases for your program. The course also covers creating conceptual models of your program with design patterns, class and sequence diagrams, and unified modeling language (UML) tools, and then shows how to convert the diagrams into code.
- Why use object-oriented design (OOD)?
- Pinpointing use cases, actors, and scenarios
- Identifying class responsibilities and relationships
- Creating class diagrams
- Using abstract classes
- Working with inheritance
- Creating advanced UML diagrams
- Understanding object-oriented design principles
Example: the singleton pattern
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.
There are currently no FAQs about Foundations of Programming: Object-Oriented Design.