In this lecture, we'll look at the Singleton pattern. As the Gang of Four described, the intent of this pattern, we ensure a class has only a single instance, and we provide a global point of access to that class. There is a very strong and reasonable objection to the Singleton pattern, and that objection is that it provides access to global state. And in the software engineering community, people have recognized that global variables are a bad thing, in general, for maintainability, and so on. So there is an alternative to the Singleton pattern, and it's the static class. But there's a problem with static classes, as well. Because even though static classes, we know we only have one instance of them, and we know they provide global access to the class, that still doesn't keep people from changing whatever global state is held in that static class. Now, if we have a static class that exposes read-only information, that's perfectly fine, from a good software architecture perspective. So our configuration utils, for example. When we were providing access to configuration data for a particular game, that configuration utils class was a static utility class that provided access to global game state, but it is read-only access, so that was perfectly fine. Sometimes though, even a static class doesn't work. So for example, if we want to attach a script to a game object, we can't attach a static class to a game object. So we may need to have some other approach to get the same ideas behind one instance of an object and global access to that instance. So let's go look at an example that we've seen before. Remember, this is not an implementation of the Singleton design pattern. It is taking advantage of the beneficial ideas in that pattern without any of the dangerous stuff. So here we have our game audio source. And remember, this is the single audio source for the entire game. In the Awake method, we check to see if the AudioManager has not been initialized yet. Because the game object this game audio source script is attached to is in the main menu scene, we could return to that scene multiple times. Each time we do, Awake will get called on the game audio source. So we need to make sure we only have one of these in the game. We don't want to create one every time we go to the main menu. So there is that piece of the Singleton design pattern that says, there's only one of them. We can tell whether or not we already have one by checking to see if the AudioManager is initialized. And if it is, we already have one, which means this one's a duplicate game object, so we destroy it. If the AudioManager isn't initialized, then we add an audio source component to this game object. We call the AudioManager.Initialize method with that audio source. And then we say, DontDestroyOnLoad the game object, which makes this game object persist across all the scenes in the game. In the AudioManager, we have a field to hold the AudioSource. We have a flag to tell whether or not we've been initialized yet. And this other stuff is a dictionary of audio clips, so we can play the appropriate audio clip when necessary. This is just the property we saw the game audio source script access, to tell whether or not the AudioManager has been initialized yet. This is the method that it calls. And we set that flag to true because now we have been initialized. We save that audio source into our field. And then we add audio clips to that dictionary of audio clips for all the sound effects that we might want to play as we play the game. Here's the other piece of the idea behind the Singleton design pattern. Any other object in the game can call the Play method, with an AudioClipName. And here, the audioSource plays the audio clip in the dictionary with the given name, and PlayOneShot is a fire and forget. You just play it and then you can move on, which is great when you might want to be playing a bunch of audio clips at the same time with a single audio source. So this is the global access to the audioSource object. But as you can see, there's nothing that any other object can do to sort of break our global state in the game. But we are providing global access to this audio source that we only have one instance of in the game. To recap, even though the Singleton pattern has fallen out of favor, it is still reasonable to use variations of that pattern in particular situations.
