Singleton Design Pattern: Meyers Method

The Singleton design pattern is a creational design pattern that ensures that only one instance of a class can be created throughout the lifetime of an application. The Singleton pattern is used when we need to ensure that there is only one instance of a class, and that this instance can be accessed from anywhere within the application.

The Singleton pattern involves creating a private static instance of the class. The constructor of the class is made private, so that no other instance of the class can be created from outside the class. The copy constructor and assignment operator should also be deleted. A public static method is then provided to access the single instance of the class, usually named Instance() or Get().

The Singleton pattern has sometimes been considered an anti-pattern within the development community. However, I would disagree with this opinion and encourage an open-mind with all design patterns within programming, as they can occasionally have their uses and sometimes are entirely necessary.

Prior to using a Singleton design pattern, it is vital you ask yourself the following questions:

1. Do we need to have global access to the object throughout our program?

2. Do we only need one instance, or is there a chance we may need more in the future?

3. Do we need an object, or can we achieve what we need using a static class or free function within a namespace? Do we have any variables?

4. Do we need the instance to be created on the heap or the stack? How big is our class going to be in memory once fully defined, and do we want to have complete control over the creation and destruction of the object? Note that creating a local static variable within a function using lazy initialization ensures the variable will get initialized the first time the Instance() or Get() function is called.

5. Do we plan to expand our class using inheritance, or will we require dependency injection?

6. Are we using threads? Is our implementation going to be thread-safe?

Now I am going to show you a few examples of where you should and should not use the Singleton pattern.

Bad Example

Suppose we have a Player class in our game, and we know we only need one instance of it. At first, the class is simple and we create it on the stack for ease of use. However, as the game grows and other classes start to depend on the Player class, it becomes larger in size and more difficult to manage. We might want to implement a second Player instance for co-op mode or have multiple character classes, and we might need to use threading for multiplayer games.

Implementing the Singleton pattern in this way, where we have a global instance of the Player class, is not a good idea. It can lead to confusion and make it difficult to manage dependencies. Instead, we should only create one instance of the Player class if needed and supply a reference to it.

Now, I am going to demonstrate how I use the Singleton design pattern. First, I review the list of questions mentioned earlier and answer them honestly. If all the criteria are met, I ask myself an additional question: is this class a game object or a game component? I ask this question because we want game objects and components to be interchangeable, enabling powerful dependency injection in the future. Creating a game object or component as a Singleton would limit our flexibility. Therefore, regarding the example of the Player class discussed earlier, the Player would be a game object, and creating it as a Singleton would be undesirable. Instead, I suggest creating one instance and providing a reference to it.

Good Example

Suppose we are loading a large number of game resources, such as binary files, text files, models, textures, audio, and shaders. Each resource has its own class responsible for loading it currently, but we need a central point where all resources can be loaded, accessed and their attributes can be stored. Without a centralized system, we might end up with multiple copies of the same resource, or we might have to pass pointers to resources all over our code. To avoid this, we can create a Resource Manager class that loads and stores all resources in one place. Since we only need one instance of this class and we want it to be accessible throughout our program, the Singleton pattern is a good choice for implementing it. However, we should still consider other design patterns and make sure we pass all the necessary checks before implementing the Singleton pattern.

In summary, the Singleton design pattern allows for only one instance of a class to be created throughout an application. To implement this pattern, a private static instance of the class is created, and a public static method is provided to access the single instance. Before using this pattern, it's crucial to consider factors like whether global access to the object is necessary and if there may be a need for multiple instances in the future. The pattern is useful for centralized systems like a Resource Manager class, but it's not suitable for classes like the Player class, which should only have one instance and a reference provided when needed.

If you want to see an example of a Singleton class using Meyers method and how we can implement it in our code, you can check out my implementation on Github at the link below.

Meyers Singleton