Swift Design Patterns

2.3 Singleton

The next type of creational design pattern that I would like to spend a few moments talking to you about is what's known as a singleton. Now a singleton sounds like a very complex idea but in actuality it's fairly simplistic. The idea behind the singleton pattern and really what the singleton pattern is for, is to just take the idea of an instance of a type. So let's say I've created a class and I've created an instance of that class, what the singleton pattern does is it allows us to every time we refer to that class or to that specific instance of that class, we're always getting the same instance back. So what does that really mean? Well, in a lot of situations within software, when you start to go to different parts of your application, you may be creating new instances of a type, new instances of a factory, new instances of other types or classes within your application. And that sometimes is good, but sometimes that's bad. Because let's say that for instance you're dealing with some sort of configuration within your application. And let's say that that particular configuration is in charge of things like connections to a database, or maybe connections to some sort of web service that you want to communicate with. Well, it would be very beneficial to not have to worry about resetting up that configuration every single time that you want to use it to have the correct connection string to a database. Or have the correct URL to a web service. It would be nice to kind of set it up one time and then just statically refer to that type or that instance anywhere in your application and know that you're always getting that same object back and consequently the same configuration properties as well. Because let's say I created a configuration class like I did for the abstract factory example, every single time I set up those classes I have to reset them up the same way. I have to set up my configuration to always be correct. So let's say I wanted to create a configuration to connect to a database, every single time I got an instance of that configuration object, I have to set that connection string property. Maybe I have to set the timeout properties and if I set them incorrectly, then I have the possibility of having two distinct configuration objects within my application and heaven forbid even more than two. I can have multiple, tens or dozens or hundreds of those configuration objects bouncing around my application with different configuration properties set to different things, that's incredibly dangerous. So that's where the singleton pattern comes in so that I can set it up one time. And then I can easily refer to those properties anywhere in my application without having to constantly pass this object around as a parameter to some of these methods. So let´s see what this will look like. So we´re gonna call this one SingletonPattern. And we´re gonna hit Next here and once again, we're gonna drop this in our Creational folder, just like that. Now the concept here is actually pretty simple and it's probably one of the easiest ones to set up in most programing languages surprisingly enough, even though it sounds like it can be pretty complex. So let's play with that configuration concept again. Let's say within my application, I have a class and that class is called Configuration. And this is going to be what's going to allow me to set up different things like a connection string, or a timeout for the database. Things that are very important. So let's set up a couple properties just as an example. So let's say we have a connection string and that's going to be a string and you could just set it to something if you want. Some fancy connection string, and then also maybe we have a timeout. Maybe we only allow attempting to make a connection to that database for some number of milliseconds or something like that. But that would be something that would be beneficial to store as a configuration property too. And let's say that's gonna be an integer and maybe it's 1000 milliseconds, or a second, or something like that, I think you get the idea. But now, if I wanted to use this in most cases or in most places throughout my application, I would have to create a configuration object, right? I'd have to say var config is equal to Configuration and then, obviously, I could change these properties if I wanted to. But then anywhere else in my application that I wanna use this, I have to do one of two things. I either have to pass this config variable all around my application as parameter methods or parameter arguments. Or I have to recreate this Configuration object in different parts of my application depending on where I need it. Now, as I said before, by default this is my connection string so everywhere else in my application I'd have to create a new instance of my configuration. And then I would have to reset it to whatever the proper connection string is. And that's very error prone and we don't want to do that. It would be nice to be able to use this class here statically, if possible, anywhere throughout our application and always know that we're going to be dealing with whatever the currently set values are. Or if we need to set those values for the connection string or the timeout to something else, we know that if we set it in one place it's going to resonate in other parts of our application. So in order to do that we're actually going to make a slight modification to our configuration and it's actually gonna be quite simple. All we really need to do is two things. What we're going to do is we are going to create a static constant here. We're gonna say static let instance be equal to configuration. So I'm creating a static constant, which means I can get access to this instance property anywhere without having to create a new instance of my class. What does that look like? So I can do something like this, configuration.instance. Great, well what does that do for me? Well, before that does anything for us, what we have to do now is we have to protect this class and not allow any sort of initialization of this class from the outside world. So as you saw there, I said configuration. As you can see in here there's an init, so by default we get this init kind of constructor in our class, we don't want that. We want to hide that from the outside world, because if we allow people to create instances of this, then everything that we're doing is for naught. Because then they can create a new instances of configuration and overwrite these and have different configurations all throughout the application. And, once again, that's very dangerous. So in order to hide that, we're actually going to do private init and we're going to leave that as an empty implementation. So what we're doing here, is we're saying the initialization function, or that constructor of our class is private and is only accessible from within this class. So then, later on if I want to come here to configuration, all of a sudden that init function is now gone. I cannot initialize a new instance of this configuration class anywhere within my application. All I have access to is this instance property. So how do we use this? Well, now because this is static and I don't have to create a new instance of my configuration class, anywhere within my application if I need to get the connection string that's currently set up, or the current timeout value, all I have to do is say Configuration.instance.connectionString. And from there I'm gonna get back whatever the currently configured connection string is. As you can see here, some fancy connection string. And the same thing is going to work for the timeout value. Anywhere within that application that I attempt to retrieve that, I'm going to get that 1000 value that's been configured in one spot. And so at any other point throughout my application, if I wanted to update that I could say, instance.connectionString equal to something else, like that. And now anywhere else within my application that I want to try to get a hold of this, once again once I ask for my connection string, it's now going to be something else. So that's where the power of the singleton comes into play. And that now I can set up all of my configuration properties in one place. And I know that every time I retrieve this particular instance, I'm getting the same value no matter where I am throughout the application and I don't have to pass around or risk misconfiguring this class all over my application.