Singleton Pattern

Ensure only one instance exists - control access to shared resources!

Singleton Pattern: One Instance to Rule Them All

Now let’s dive into the Singleton Pattern - a creational design pattern that ensures a class has only one instance and provides a global point of access to it.

Why Singleton Pattern?

Imagine a pizza shop. You only need one manager to coordinate everything - you don’t want multiple managers giving conflicting orders! The Singleton Pattern works the same way!

The Singleton Pattern ensures that a class has only one instance and provides a global point of access to that instance. Instead of creating multiple instances, everyone uses the same one.

What’s the Use of Singleton Pattern?

The Singleton Pattern is useful when:

You need exactly one instance - Multiple instances would cause problems
Shared resource management - Database connections, file systems, caches
Global configuration - Application settings that should be consistent
Logging systems - One logger instance for the entire application
Resource-intensive objects - Objects that are expensive to create (only create once)
State management - When you need a single source of truth

What Happens If We Don’t Use Singleton Pattern?

Without the Singleton Pattern, you might:

Create multiple instances - Wasting memory and resources
Inconsistent state - Different parts of code using different instances
Resource conflicts - Multiple connections to the same resource
Configuration chaos - Different parts reading different configurations
Performance issues - Creating expensive objects multiple times
Race conditions - Multiple instances competing for the same resource

Simple Example: The Pizza Shop Manager

Let’s start with a super simple example that anyone can understand!

Visual Representation

Interaction Flow

Here’s how the Singleton Pattern works in practice - showing how multiple clients get the same instance:

sequenceDiagram
    participant Client1
    participant Client2
    participant Client3
    participant Singleton as PizzaShopManager
    
    Client1->>Singleton: get_instance()
    activate Singleton
    Singleton->>Singleton: Check if instance exists
    Singleton->>Singleton: Create instance (first time)
    Singleton-->>Client1: Returns instance #1
    deactivate Singleton
    
    Client2->>Singleton: get_instance()
    activate Singleton
    Singleton->>Singleton: Check if instance exists
    Singleton-->>Client2: Returns same instance #1
    deactivate Singleton
    
    Client3->>Singleton: get_instance()
    activate Singleton
    Singleton->>Singleton: Check if instance exists
    Singleton-->>Client3: Returns same instance #1
    deactivate Singleton
    
    Note over Client1,Singleton: All clients get<br/>the SAME instance!

The Problem

You’re building a pizza shop system. You need a manager to coordinate orders, but you only want one manager - having multiple managers would cause chaos! Without Singleton Pattern:

Problems:

Multiple instances with different states
No single source of truth
Memory waste
Inconsistent data across the application

The Solution: Singleton Pattern

Class Structure

classDiagram
    class PizzaShopManager {
        -_instance: PizzaShopManager
        -orders: List
        +__new__() PizzaShopManager
        +add_order(order) void
        +get_orders() List
    }
    class Client1 {
        +get_manager() PizzaShopManager
    }
    class Client2 {
        +get_manager() PizzaShopManager
    }
    class Client3 {
        +get_manager() PizzaShopManager
    }
    
    Client1 --> PizzaShopManager : gets instance
    Client2 --> PizzaShopManager : gets instance
    Client3 --> PizzaShopManager : gets instance
    
    note for PizzaShopManager "Only ONE instance<br/>exists globally"
    note for PizzaShopManager "All clients get<br/>the same instance"

Real-World Software Example: Database Connection Manager

Now let’s see a realistic software example - a database connection manager that should only have one instance to manage connection pooling efficiently.

The Problem

You’re building an application that needs database access. Creating multiple connection managers would waste resources and cause connection pool conflicts. Without Singleton Pattern:

Problems:

Multiple connection pools wasting resources
Expensive initialization happens multiple times
No shared connection management
Potential connection pool exhaustion

The Solution: Singleton Pattern

Singleton Pattern Variants

There are several ways to implement the Singleton Pattern:

1. Eager Initialization (Simple Singleton)

The instance is created when the class is loaded:

Pros: Simple, thread-safe
Cons: Instance created even if never used

2. Lazy Initialization (On-Demand)

The instance is created only when first requested:

Pros: Instance created only when needed
Cons: Not thread-safe (can create multiple instances in multi-threaded environment)

3. Thread-Safe Singleton (Double-Check Locking)

Thread-safe version using double-check locking:

Pros: Thread-safe, lazy initialization
Cons: Slightly more complex

4. Singleton with Module Pattern (Python-specific)

In Python, modules are naturally singletons:

Python

1
# singleton_module.py
2
class _Singleton:
3
    def __init__(self):
4
        self.value = None
5

6
# Module-level instance
7
_instance = _Singleton()
8

9
def get_instance():
10
    return _instance
11

12
# Usage: from singleton_module import get_instance
13
# This is the most Pythonic way!

Pros: Most Pythonic, simple
Cons: Python-specific

When to Use Singleton Pattern?

Use Singleton Pattern when:

✅ Exactly one instance needed - Multiple instances would cause problems
✅ Global access required - Need to access from anywhere in the application
✅ Expensive resource - Object is expensive to create (database connections, file handles)
✅ Shared state - Need a single source of truth
✅ Configuration management - Application-wide settings
✅ Logging systems - One logger for the entire application
✅ Caching - Single cache instance
✅ Thread pools - Single thread pool manager

When NOT to Use Singleton Pattern?

Don’t use Singleton Pattern when:

❌ Multiple instances needed - If you might need multiple instances, don’t use Singleton
❌ Testing difficulties - Singletons can make unit testing harder
❌ Hidden dependencies - Global state can hide dependencies
❌ Concurrency issues - Can cause problems in distributed systems
❌ Violates Single Responsibility - Can become a “god object”
❌ Tight coupling - Creates global coupling

Common Mistakes to Avoid

Mistake 1: Not Making Constructor Private

Mistake 2: Not Thread-Safe in Multi-Threaded Environment

Mistake 3: Serializable Singleton Without readResolve

Java

1
import java.io.Serializable;
2

3
// ❌ Bad: Serializable singleton without readResolve
4
public class BadSerializableSingleton implements Serializable {
5
    private static final long serialVersionUID = 1L;
6
    private static BadSerializableSingleton instance = new BadSerializableSingleton();
7

8
    private BadSerializableSingleton() {}
9

10
    public static BadSerializableSingleton getInstance() {
11
        return instance;
12
    }
13

14
    // Problem: Deserialization creates a new instance!
15
    // Need readResolve() method to return the singleton instance
16
}
17

18
// ✅ Good: With readResolve
19
public class GoodSerializableSingleton implements Serializable {
20
    private static final long serialVersionUID = 1L;
21
    private static GoodSerializableSingleton instance = new GoodSerializableSingleton();
22

23
    private GoodSerializableSingleton() {}
24

25
    public static GoodSerializableSingleton getInstance() {
26
        return instance;
27
    }
28

29
    // Prevents deserialization from creating a new instance
30
    protected Object readResolve() {
31
        return getInstance();
32
    }
33
}

Mistake 4: Using Singleton for Everything

Benefits of Singleton Pattern

Controlled Access - Only one instance exists, controlled access point
Resource Efficiency - Expensive objects created only once
Global State - Single source of truth for shared state
Memory Efficient - No memory waste from multiple instances
Lazy Initialization - Can defer expensive initialization until needed
Namespace - Provides a namespace for global variables

Revision: Quick Catch-Up

What is Singleton Pattern?

Singleton Pattern is a creational design pattern that ensures a class has only one instance and provides a global point of access to that instance.

Why Use It?

✅ Exactly one instance - Multiple instances would cause problems
✅ Resource efficiency - Expensive objects created only once
✅ Global access - Easy to access from anywhere
✅ Shared state - Single source of truth
✅ Memory efficient - No waste from multiple instances

How It Works?

Private constructor - Prevents external instantiation
Static instance variable - Stores the single instance
Static getter method - Returns the instance (creates if needed)
Controlled creation - Only one instance can exist

Key Components

1
Client → getInstance() → Singleton Instance

Singleton Class - Class with private constructor
Static Instance - The single instance variable
Getter Method - Method to get the instance
Client - Code that uses the singleton

Simple Example

1
class Singleton:
2
    _instance = None
3

4
    def __new__(cls):
5
        if cls._instance is None:
6
            cls._instance = super(Singleton, cls).__new__(cls)
7
        return cls._instance
8

9
# Usage
10
obj1 = Singleton()
11
obj2 = Singleton()
12
print(obj1 is obj2)  # True - same instance!

When to Use?

✅ Exactly one instance needed
✅ Expensive resource creation
✅ Global access required
✅ Shared state management
✅ Configuration management
✅ Logging systems

When NOT to Use?

❌ Multiple instances might be needed
❌ Testing difficulties are a concern
❌ Hidden dependencies are problematic
❌ Distributed systems
❌ Violates Single Responsibility

Key Takeaways

Singleton Pattern = Only one instance exists
Private Constructor = Prevents external creation
Static Getter = Controlled access point
Benefit = Resource efficiency and global access
Caution = Use judiciously, can make testing harder

Common Pattern Structure

1
class Singleton:
2
    _instance = None
3

4
    def __new__(cls):
5
        if cls._instance is None:
6
            cls._instance = super(Singleton, cls).__new__(cls)
7
        return cls._instance
8

9
    @classmethod
10
    def get_instance(cls):
11
        return cls()
12

13
# Usage
14
instance = Singleton.get_instance()

Remember

Singleton Pattern ensures only one instance exists
It provides controlled access to that instance
Use it for expensive resources or shared state
Don’t overuse it - can make code harder to test
Consider alternatives like dependency injection

Interview Focus: Singleton Pattern

Key Points to Remember

1. Core Concept

What to say:

“Singleton Pattern is a creational design pattern that ensures a class has only one instance and provides a global point of access to that instance. It’s useful for managing shared resources like database connections, loggers, or configuration managers.”

Why it matters:

Shows you understand the fundamental purpose
Demonstrates knowledge of when to use it
Indicates you can explain concepts clearly

2. When to Use Singleton Pattern

Must mention:

✅ Exactly one instance needed - Multiple instances would cause problems
✅ Expensive resource - Database connections, file handles
✅ Global access - Need to access from anywhere
✅ Shared state - Single source of truth
✅ Configuration - Application-wide settings

Example scenario to give:

“I’d use Singleton Pattern for a database connection manager. Creating multiple connection managers would waste resources and cause connection pool conflicts. With Singleton, all parts of the application share the same connection pool.”

3. Structure and Components

Must explain:

Private Constructor - Prevents external instantiation
Static Instance Variable - Stores the single instance
Static Getter Method - Returns the instance (creates if needed)
Controlled Creation - Ensures only one instance exists

Visual explanation:

1
Client → getInstance() → Singleton Instance (created once, reused always)

4. Thread Safety

Must discuss:

Problem: Multiple threads can create multiple instances
Solution: Use synchronization (locks, synchronized blocks)
Double-Check Locking: Check twice, lock once

Example to give:

“In a multi-threaded environment, multiple threads might check if the instance is null at the same time and both create instances. To prevent this, I use double-check locking - check if instance is null, acquire lock, check again, then create.”

5. Benefits and Trade-offs

Benefits to mention:

Resource Efficiency - Expensive objects created only once
Global Access - Easy to access from anywhere
Controlled Access - Single point of control
Memory Efficient - No waste from multiple instances

Trade-offs to acknowledge:

Testing Difficulties - Hard to mock and test
Hidden Dependencies - Global state hides dependencies
Tight Coupling - Creates global coupling
Concurrency Issues - Can cause problems in distributed systems

6. Common Interview Questions

Q: “What’s the difference between Singleton and Static Class?”

“A Singleton is an instance of a class that can be created, while a static class cannot be instantiated. Singleton can implement interfaces and be passed as parameters, while static classes cannot. Singleton allows lazy initialization, while static classes are initialized when the class is loaded.”

Q: “How do you make Singleton thread-safe?”

“I use double-check locking - first check if instance is null without locking (for performance), then acquire a lock, check again (to prevent race conditions), and create the instance if still null. Alternatively, I can use eager initialization or synchronized methods, but double-check locking provides the best balance of thread safety and performance.”

Q: “What are the problems with Singleton Pattern?”

“Singleton Pattern can make unit testing difficult because you can’t easily mock the singleton. It also creates hidden dependencies and tight coupling. In distributed systems, each process has its own singleton instance, which can cause inconsistencies. Additionally, it violates the Single Responsibility Principle if the singleton does too much.”

7. Implementation Details

Key implementation points:

Private Constructor - Prevents external instantiation

1
def __new__(cls):
2
    if cls._instance is None:
3
        cls._instance = super(Singleton, cls).__new__(cls)
4
    return cls._instance

Thread-Safe Implementation - Use locks for multi-threaded environments

1
_lock = threading.Lock()
2
with cls._lock:
3
    if cls._instance is None:
4
        cls._instance = super(Singleton, cls).__new__(cls)

Lazy vs Eager Initialization - Choose based on needs
- Lazy: Create when first accessed
- Eager: Create when class is loaded
Serialization (Java) - Implement readResolve() to prevent new instances

8. Real-World Examples

Good examples to mention:

Database Connection Manager - Single connection pool
Logger - One logger instance for the application
Configuration Manager - Application-wide settings
Cache Manager - Single cache instance
Thread Pool Manager - Single thread pool

9. Common Mistakes to Avoid

Mistakes interviewers watch for:

Not Thread-Safe - Can create multiple instances
- ❌ Bad: No synchronization in multi-threaded environment
- ✅ Good: Use double-check locking or synchronized methods
Public Constructor - Allows external instantiation
- ❌ Bad: Public constructor
- ✅ Good: Private constructor
Serialization Issues (Java) - Deserialization creates new instance
- ❌ Bad: Serializable without readResolve()
- ✅ Good: Implement readResolve() method
Overuse - Using Singleton for everything
- ❌ Bad: Singleton for classes that need multiple instances
- ✅ Good: Use Singleton only when exactly one instance is needed

10. Alternatives to Singleton

Be ready to discuss:

Dependency Injection - Pass instance as parameter
Service Locator - Central registry for services
Monostate Pattern - All instances share the same state
Factory Pattern - Can return the same instance

When to use alternatives:

“If testing is a priority, I might use dependency injection instead of Singleton. This makes it easier to mock dependencies and test components in isolation.”

Interview Checklist

Before your interview, make sure you can:

Remember: Singleton Pattern ensures only one instance exists, providing controlled access to shared resources. Use it judiciously - it’s powerful but can make code harder to test! 🎯

Request a feature or report an issue