JS Design Patterns — Singleton State Leaks in Tests

Simple enough. But the real win isn't just centralised creation — it's that your callers never need to know the concrete class. They work against an interface or a common contract. Swap the implementation later without touching callers.

Where people trip up: using a Factory for a single implementation. That's just indirection without benefit. And factories that return different shapes under the same name cause runtime errors that type checkers won't catch.

/**
 * io.thecodeforge - Factory Pattern Implementation
 */
class DatabaseConnector {
    constructor(config) {
        this.config = config;
    }
    connect() { throw new Error("Method 'connect()' must be implemented."); }
}

class PostgreSqlConnector extends DatabaseConnector {
    connect() { return `Connected to Postgres at ${this.config.host}`; }
}

class MongoDbConnector extends DatabaseConnector {
    connect() { return `Connected to MongoDB at ${this.config.uri}`; }
}

class DBFactory {
    static createConnection(type, options) {
        switch(type) {
            case 'SQL': return new PostgreSqlConnector(options);
            case 'NoSQL': return new MongoDbConnector(options);
            default: throw new Error("Unsupported DB type");
        }
    }
}

const db = DBFactory.createConnection('SQL', { host: 'localhost' });
console.log(db.connect());

The Singleton Pattern: Ensuring a Single Source of Truth

A Singleton restricts a class to a single instance and provides a global point of access to it. While often criticized if overused as 'global state,' it is vital for resource-heavy objects like Database Pools or Global Configuration managers where multiple instances would cause memory leaks or race conditions.

JavaScript's module system makes singletons deceptively easy — a module-level variable survives as long as the process. But that's also the trap: in a serverless environment, each cold start gets a new instance, but warm starts reuse the same. That inconsistency breaks assumptions.

Modern ES2022+ private static fields (#instance) give you real encapsulation. The old pattern of storing the instance on the constructor function itself is still common but less clean.

/**
 * io.thecodeforge - Modern ES6 Singleton using Static Private Fields
 */
class GlobalConfig {
    static #instance = null;

    constructor() {
        if (GlobalConfig.#instance) {
            return GlobalConfig.#instance;
        }
        this.settings = { theme: 'dark', version: '2.1.0' };
        GlobalConfig.#instance = this;
    }

    static getInstance() {
        if (!this.#instance) {
            this.#instance = new GlobalConfig();
        }
        return this.#instance;
    }
}

const configA = new GlobalConfig();
const configB = GlobalConfig.getInstance();
console.log(configA === configB);

The Behavioral King: The Observer Pattern

The Observer pattern (the core of 'Pub/Sub' logic) allows an object (the Subject) to notify a list of 'Observers' about state changes. This is how event listeners work in the browser and how frameworks like React and Vue trigger UI updates when state changes.

The simplicity of Observer is also its biggest risk: observers hold references to subscribers, and if those subscribers aren't properly cleaned up, you get memory leaks and ghost callbacks. In a single-page application, forgetting to unsubscribe on component unmount is the number one cause of stale state and unexpected behaviour.

Modern JavaScript provides WeakRef and FinalizationRegistry to help, but most common implementations just store arrays of callbacks — manual cleanup is your responsibility.

/**
 * io.thecodeforge - Simple Event Bus (Observer Pattern)
 */
class EventBus {
    constructor() {
        this.subscribers = {};
    }

    subscribe(event, callback) {
        if (!this.subscribers[event]) this.subscribers[event] = [];
        this.subscribers[event].push(callback);
    }

    publish(event, data) {
        if (!this.subscribers[event]) return;
        this.subscribers[event].forEach(cb => cb(data));
    }

    unsubscribe(event, callback) {
        if (!this.subscribers[event]) return;
        this.subscribers[event] = this.subscribers[event].filter(cb => cb !== callback);
    }
}

const forgeBus = new EventBus();
forgeBus.subscribe('USER_LOGIN', (user) => console.log(`Welcome, ${user}!`));
forgeBus.publish('USER_LOGIN', 'ForgeAdmin');

The Module Pattern: Encapsulation Before ES Modules

The Module pattern was the go-to way to create private scope before ES2015 modules. It uses an IIFE (Immediately Invoked Function Expression) to return a public API while keeping internal variables hidden. Even now, understanding it helps you read older codebases and makes you appreciate what import/export gives you.

The key insight: closures provide true private state. No prefix conventions like _private needed — the variable simply isn't accessible from outside. But the downside: each module creates its own closure, consuming memory for the lifetime of the module. And if you need to share a module across files, you need a script tag loader or a bundler.

Today, most teams use ES modules instead. But the Module pattern is still useful for inline scripts or when you can't use a bundler.

/**
 * io.thecodeforge - Module Pattern (IIFE)
 */
const ForgeCounter = (function () {
    // Private
    let count = 0;

    function increment() {
        count++;
    }

    function decrement() {
        count--;
    }

    // Public API
    return {
        add: function (amount) {
            count += amount;
        },
        getCount: function () {
            return count;
        },
        reset: function () {
            count = 0;
        }
    };
})();

ForgeCounter.add(5);
console.log(ForgeCounter.getCount()); // 5
console.log(ForgeCounter.count); // undefined (private)

The Strategy Pattern: Swap Algorithms at Runtime

The Strategy pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. The calling code uses a common interface, so you can swap strategies without touching the caller. This is invaluable for things like payment gateways, sorting algorithms, or validation rules that differ by user type or region.

In JavaScript, strategies are often just functions or objects with a common method signature. The pattern becomes especially powerful when combined with dependency injection or configuration files.

Common trap: creating a new strategy for every minor variation. If the variation is just a parameter, a simple function with a parameter is cleaner. Strategy is for when the entire behaviour changes, not just a value.

/**
 * io.thecodeforge - Strategy Pattern for Payment
 */
class PaymentContext {
    constructor(strategy) {
        this.strategy = strategy;
    }

    setStrategy(strategy) {
        this.strategy = strategy;
    }

    executePayment(amount) {
        return this.strategy.pay(amount);
    }
}

const stripeStrategy = {
    pay(amount) { return `Paid $${amount} via Stripe`; }
};

const paypalStrategy = {
    pay(amount) { return `Paid $${amount} via PayPal`; }
};

const payment = new PaymentContext(stripeStrategy);
console.log(payment.executePayment(100));
payment.setStrategy(paypalStrategy);
console.log(payment.executePayment(50));