Singleton Pattern

#designpatterns #typescript

In the world of software architecture, we often encounter objects that should only exist once. Whether it’s a configuration manager, a print spooler, or a database connection pool, having multiple instances floating around can lead to unpredictable behavior, resource exhaustion, or data inconsistency.

This is where the Singleton Pattern comes in. As a senior developer, I view the Singleton as a "utility" pattern—it’s incredibly powerful when used correctly, but it can be a double-edged sword if misapplied.

What is a Singleton?

At its core, the Singleton is a creational design pattern that ensures a class has only one instance while providing a global point of access to that instance.

Think of it like the pilot of a commercial airplane. There might be hundreds of passengers and several flight attendants, but there is only one person (or one specific role) in charge of the flight deck at any given time. You wouldn’t want two different pilots trying to steer the plane in two different directions!

Anatomy of a Singleton

To create a Singleton, a class must follow three strict rules:

Private Constructor: This prevents other classes from using the new keyword to create instances.
Static Field: A private variable within the class to hold the single instance.
Static Method: A public method (usually called getInstance()) that returns the instance, creating it first if it doesn't already exist.

Real-World Example: The Global Logger

Logging is the quintessential use case for a Singleton. You want every part of your application—from the login logic to the payment processing—to send messages to the same log file or console.

Here is how we implement a robust, thread-safe (in concept) Logger in TypeScript:

class Logger {
    private static instance: Logger;
    private logs: string[] = [];

    // 1. Private constructor prevents 'new Logger()'
    private constructor() {
        console.log("Logger Initialized.");
    }

    // 2. The static method that controls access
    public static getInstance(): Logger {
        if (!Logger.instance) {
            Logger.instance = new Logger();
        }
        return Logger.instance;
    }

    // A simple business method
    public log(message: string): void {
        const timestamp = new Date().toISOString();
        const fullMessage = `[${timestamp}] ${message}`;
        this.logs.push(fullMessage);
        console.log(fullMessage);
    }

    public getLogCount(): number {
        return this.logs.length;
    }
}

// --- Usage ---

// const logger = new Logger(); // Error: Constructor of class 'Logger' is private.

const loggerA = Logger.getInstance();
const loggerB = Logger.getInstance();

loggerA.log("User logged in.");
loggerB.log("Order processed.");

console.log(loggerA === loggerB); // true - both variables point to the exact same memory

The Pros: Why We Use It

Controlled Access: You have total control over how and when the instance is accessed.
Reduced Memory Footprint: Instead of creating 100 objects for 100 different modules, you keep just one in memory.
Lazy Initialization: The instance is only created when it’s actually needed. If your app never calls getInstance(), the object is never born.
Global State Management: It provides a synchronized place to store data that needs to be shared across the entire system.

The Trade-offs: The "Hidden" Costs

Every senior dev will tell you: Singletons are controversial. Here’s why:

The "Global Variable" Problem: Singletons are essentially glorified global variables. They can make code harder to debug because any part of the app can change the state of the Singleton at any time.
Testing Hurdles: Since Singletons persist state between tests, they can cause "leaky" tests. If Test A changes the Logger's state, Test B might fail unexpectedly because it’s still using that same modified instance.
Violation of Single Responsibility: The class is responsible for two things: its actual job (e.g., logging) and managing its own lifecycle/uniqueness.
Tight Coupling: Classes that use the Singleton become tightly coupled to that specific implementation, making it harder to swap out for a different version later.

Final Verdict

The Singleton Pattern is a tool, not a rule.

Use it when you have a shared resource that absolutely must be unique to maintain consistency (like a file system driver or a central state store).

Avoid it if you’re just using it as a convenient way to access variables from anywhere. In modern development, we often prefer Dependency Injection to pass instances around, which gives us the "one instance" benefit without the testing headaches of a hard-coded Singleton.

DEV Community