What is the Singleton Pattern?

The Singleton pattern ensures that a class has only one instance and provides a global access point to it. This is useful when you need shared state or control over object creation.

🏗 Common Use Cases

• Logging services – Centralize log writing so every part of your app logs to the same place.
• Configuration managers – Ensure consistent settings across your application.

When Should You Avoid Singleton?

While Singletons can be useful, they are often overused. Here are some cases where you might want to reconsider using one:

❌ Hidden Dependencies – Since the Singleton is globally accessible, other classes may start relying on it implicitly, making the code harder to maintain.
❌ Unit Testing Challenges – Singletons introduce global state, making it harder to isolate functionality in unit tests.
❌ Potential Bottlenecks – If multiple parts of your app depend on a single instance, it could become a performance bottleneck.

---

Implementing Singleton in C#

Here’s a thread-safe Singleton implementation in C#:

sealed class Logger
{
    private static readonly Lazy<Logger> _lazyInstance = new(() => new());
    public static Logger Instance => _lazyInstance.Value;

    private Logger()
    {
        Console.WriteLine("Instantiating logger");
    }
    
    public void Log(string message)
    {
        Console.WriteLine(message);
    }
}

Why This Works Well

• Thread-Safe by Default – Lazy<T> ensures that the instance is created only when needed and prevents race conditions.
• Sealed Class – Prevents accidental subclassing, keeping behavior predictable.
• Private Constructor – Ensures that no one can instantiate Logger manually. Now, let’s test it:

Logger singleton1 = Logger.Instance;
Logger singleton2 = Logger.Instance;

If you run this code in a console app, you’ll see only one instance is created, no matter how many times you access Logger.Instance:

Instantiating logger

Dependency Injection with Singleton

If you’re using a DI container, you can register the Singleton instance like this:

services.AddSingleton<Logger>();

This way, you can inject the Logger into other classes without worrying about creating multiple instances.

public class MyClass
{
    private readonly Logger _logger;

    public MyClass(Logger logger)
    {
        _logger = logger;
    }
}
### Dependency Injection with Singleton
---

## Final Thoughts

The Singleton pattern is a **powerful tool**, but like all design patterns, it should be used **with care**.

✅ Use it when you truly need a single shared instance (e.g., logging, configuration).

❌ Avoid it when you need flexibility, testability, or multiple instances.


If you're using a DI container, you can register the Singleton instance like this:

```csharp
services.AddSingleton<Logger>();
### Dependency Injection with Singleton

If you're using a DI container, you can register the Singleton instance like this:

```csharp
services.AddSingleton<Logger>();
### Dependency Injection with Singleton

If you're using a DI container, you can register the Singleton instance like this:

```csharp
services.AddSingleton<Logger>();
### Dependency Injection with Singleton

If you're using a DI container, you can register the Singleton instance like this:

```csharp
services.AddSingleton<Logger>();