Singleton Pattern

1. Introduction

The Singleton Pattern is one of the most well-known creational design patterns. It restricts a class to a single instance and provides a global access point to it. It's useful when exactly one object is needed to coordinate actions across a system.

2. Why Use Singleton?

Instead of duplicating shared logic like logging or configuration across classes, a Singleton centralizes it — allowing safe, lazy, and efficient reuse.

3. Key Features of Singleton

• Only one instance exists throughout the application lifecycle
• Provides a global point of access to that instance
• Can be lazy-loaded (created only when needed)
• Often implemented with thread safety in mind

4. Step-by-Step Guide to Implementing Singleton in C#

Step 1: Define a private constructor

This prevents other classes from using new to create instances.

Step 2: Create a static field to hold the instance

This is where the one-and-only instance will be stored.

Step 3: Provide a static property to access the instance

This property lazily initializes the instance if it's not already created.

Singleton in Practice: Code Comparison

public class Logger
{
    private static Logger _instance;
    private Logger() {}

    public static Logger Instance => _instance ??= new Logger();

    public void Log(string message)
    {
        Console.WriteLine($"[LOG] {message}");
    }
}
        

class SingletonMeta(type):
    _instance = None

    def __call__(cls, *args, **kwargs):
        if cls._instance is None:
            cls._instance = super().__call__(*args, **kwargs)
        return cls._instance

class Logger(metaclass=SingletonMeta):
    def log(self, message):
        print(f"[LOG] {message}")
        

5. Making it Thread-Safe

Use Lazy<T> to ensure the instance is safely created even in multithreaded environments:

public class Config
{
    private static readonly Lazy _instance = new(() => new Config());

    public static Config Instance => _instance.Value;

    private Config() 
    {
        // Load configuration from a file or environment
    }
}
        

class SingletonMeta(type):
    _instance = None

    def __call__(cls, *args, **kwargs):
        if cls._instance is None:
            cls._instance = super().__call__(*args, **kwargs)
        return cls._instance

class Logger(metaclass=SingletonMeta):
    def log(self, message):
        print(f"[LOG] {message}")

# Usage
logger1 = Logger()
logger2 = Logger()
print(logger1 is logger2)  # True
        

4. Benefits

• ✅ Centralized shared logic :

  Since the Singleton ensures there's only one instance of a class (like a logger or config manager), all logic related to that functionality is centralized in that single object. This prevents scattered implementations and promotes consistency across the application.

• ✅ Memory-efficient (one instance):

  Instead of creating new objects repeatedly, the Singleton reuses a single instance. This reduces memory overhead — especially helpful for heavy or frequently used components like caches or device managers.

• ✅ Lazy-loading friendly:

  As shown in both the C# and Python examples, Singletons can be implemented with lazy initialization — creating the instance only when it’s first needed. This boosts performance by avoiding unnecessary allocation during app startup.

• ✅ Easy to implement in OOP:

  The blog gives step-by-step OOP implementations in C# and Python. With just a private constructor, a static instance field, and an accessor method, you get a reusable Singleton. It’s approachable even for those new to design patterns.

5. Pitfalls

• ❌ Hidden global state:

  Since Singletons offer global access, they behave like global variables. That makes their state available everywhere, which can introduce subtle bugs or side effects — especially in larger applications. It becomes harder to track where and how the state changes across your app, breaking encapsulation and making debugging trickier.

• ❌ Difficult to test without interfaces or DI:

  If a Singleton is tightly coupled into your classes (i.e., not injected or abstracted), unit testing becomes painful. You can’t easily swap it out with a mock. The blog even suggests that dependency injection or interface abstraction can mitigate this — which ties directly into your "Summary" point about improving testability.

• ❌ Can become a “God Object”:

  If developers keep stuffing more logic into the Singleton — configuration, logging, caching, etc. — it starts doing too much. This violates the Single Responsibility Principle and makes the class overly complex and hard to maintain. Your page wisely cautions against this, encouraging restraint and focus in Singleton responsibilities.

6. Real-World Use Cases

8. Quiz: Test Yourself

Q: What is the primary purpose of Singleton?

• A. Avoid inheritance
• B. Enable multiple logger formats
• C. Guarantee one shared instance ✅
• D. Allow constructor injection

9. Summary

Singleton is useful when you need one and only one instance to coordinate global behavior. It's powerful but should be used with caution. Always weigh testability and encapsulation before applying it blindly.

🔜 Next: Builder Pattern – Construct complex objects step-by-step

10. Related Blogs

• Factory Pattern
• SOLID Principles
• Dependency Injection