The Singleton Design Pattern

What is the purpose of singleton pattern?

Singleton is a creational design pattern that ensures only a single instance of a class exists throughout an application and provides access to that instance from anywhere in the codebase. It is useful in situations where multiple instances of a class are undesirable or a single point of control or coordination is required. Typical examples include logging systems, database connection managers, caches, and thread pools, among others.

How does the Singleton Design Pattern work?

The implementation of a Singleton class typically employs a private constructor which prevents direct instantiation of the class from outside its own implementation. It also has a private static member variable that stores a single instance of itself. This variable is typically named _instance and has a default value of null. This variable’s value can be accessed through a public static method or property, typically named GetInstance or Instance, which is responsible for instantiating or returning that single instance of the class when required. When the GetInstance method is invoked, it checks the _instance static member variable to determine if it is null, which means that no instance of the class has yet been created. In this situation, the GetInstance method creates and assigns a new instance of the class to _instance. All subsequent calls to the GetInstance method return the same instance.

We may look to a Load Balancer for an example of the Singleton design pattern. Because servers may dynamically come online and offline, only a single instance of the class can be created, and every request must pass through the single object that knows the status of a web farm.

The main program, which uses the behavior of the LoadBalancer class (the Singleton) to simulate a specific functionality, plays the Client role, as shown on the class diagram. Due to its simplicity, the only thing worth mentioning about the C# 11 sample code is that a thread-safe Lazy initialization is used for the Singleton implementation. (the code is available on GitHub)

Advantages of the Singleton Design Pattern

1. Single Instance: The Singleton Pattern guarantees that a class has only one instance throughout the application. This can be useful in scenarios in which multiple instances must be avoided, such as when managing shared resources or configurations.
2. Global Access: Because a Singleton instance is globally accessible, it is possible to access its methods and properties from anywhere in the application. This eliminates the need to pass objects’ instances or manage complex dependencies.
3. Lazy Initialization: The Singleton pattern supports lazy initialization, which means that the instance is created only when it is accessed for the first time. This can improve performance by deferring instantiation until it is required.
4. Thread Safety: The Singleton implementation can be made thread-safe, allowing multiple threads to access the instance without causing concurrency issues. This is particularly critical in multi-threaded applications.

Disadvantages of the Singleton Design Pattern

While the Singleton Design Pattern has several advantages, particularly in terms of thread safety and lazy initialization, there are certain drawbacks to consider:

1. Global State: The Singleton pattern introduces a global state, which can make it harder to track and reason about the behavior of the system. Changes to the Singleton instance can affect other application parts, potentially resulting in hidden bugs and unintended side effects.
2. Tight Coupling: As the Singleton instance is directly accessed throughout the application, the use of Singleton can lead to tight coupling between classes. This can make it more difficult to modify or replace the Singleton in the future with a different implementation.
3. Testing Challenges: Using Singletons can make unit testing more challenging. Because the Singleton instance is globally accessible, it can be challenging to isolate and test dependent components. Mocking or substituting the Singleton instance during testing may require additional work or codebase changes.
4. Difficulty in Lifecycle Management: Typically, singletons have a long lifetime, existing for the duration of the application. Managing the lifecycle of a Singleton, such as releasing resources or resetting the state, can be complicated, particularly in cases where the instance must be re-initialized.
5. Limited Extensibility: Due to their restricted instantiation and global access, it can be difficult to extend or modify Singleton classes. Introducing new variations or behaviors to the Singleton without modifying the existing implementation can be challenging, too.
6. Violates the Single Responsibility Principle: This principle states that every class should have a single task to do. In case of Singleton class, it will have two responsibility one to create an instance and other to do the actual task.
7. Breaks the Open Closed Principle: This principle can be explained in a single statement: “Open for Extension, Closed for Modification”. The Singleton class always returns its own instance and is never open for extension.

It’s important to carefully consider these disadvantages in relation to your specific use case before deciding to employ the Singleton Design Pattern.

When should we use the Singleton Design Pattern?

The Singleton Design Pattern should be used when the following conditions are met:

1. Single Instance Requirement: We need to ensure that there is only one instance of a class throughout the entire application. This can be useful in scenarios where multiple instances would lead to conflicts or inconsistencies.
2. Global Access: We want a single point of access to the instance, allowing other parts of the application to easily use and interact with it. This eliminates the need for passing instances between objects or managing complex dependencies.
3. Limited Resource Usage: The class represents a limited or expensive resource, such as a database connection, file system, or hardware device, and we want to share that resource efficiently among multiple parts of the application.
4. Coordination and Control: We need a centralized point of coordination or control, where changes made to the instance can be observed or managed by other parts of the application.

Real-world examples of Singleton Design Pattern

Some examples of how this design pattern is used in practice:

1. Logger: In many software systems, logging is an essential component for recording events and debugging purposes. A Logger class can manage logging operations throughout the application. It ensures that only one instance of the Logger exists, and all parts of the system can access it easily.
2. Database Connection: When an application needs to connect to a database, it is often beneficial to have a single, shared connection that multiple components can utilize. A DatabaseConnection class can be implemented to provide a centralized point for establishing and managing the database connection.
3. Configuration Manager: Applications often require a centralized configuration to store settings and properties. The Singleton pattern can be used to create a ConfigurationManager class that loads and manages the application configuration. This ensures that all parts of the application access the same configuration data.
4. Cache Manager: Caching is a common technique used to improve performance by storing frequently accessed data in memory. A CacheManager class can be employed to handle caching operations across the application, ensuring that only one cache instance exists and is accessible from multiple components.
5. Thread Pool: In concurrent programming, a thread pool is a common design pattern where a pool of threads is created to execute tasks. A ThreadPool class can be implemented as a Singleton to manage the creation, allocation, and execution of threads, providing a shared resource for handling concurrent tasks.

It is important to note that while Singletons can be useful in certain scenarios, they should be used judiciously. Careful consideration should be given to the specific requirements and design choices when using the Singleton pattern.

Conclusion

Depending on the specific application requirements, the Singleton pattern can be implemented with different variations, such as lazy/eager initialization, or additional thread safety measures. These variations may affect how the instance is created and accessed, but the fundamental concept of a single instance with global access remains unchanged. Also, because of its disadvantages, especially the violations of some SOLID principles and the tight coupling, the Singleton pattern is considered an Anti-Pattern.