Singleton

The three moving parts

A textbook Singleton does three small things. Together they make it impossible to get a second instance:

• A private constructor — so nobody outside the class can write new Printer(). The door to new is locked; only the class itself has the key.
• A single stored instance — the class keeps one reference to itself in a private static field (private static instance), the one and only copy.
• A public accessor — a static method getInstance() that everyone calls. The first call creates the instance and stashes it; every later call returns that same stored one.

class Printer {
  private static instance: Printer;   // the one stored copy
  private queue: string[] = [];

  private constructor() {}            // 🔒 no 'new Printer()' from outside

  static getInstance(): Printer {     // everyone comes through here
    if (!Printer.instance) {          // first call? build it once
      Printer.instance = new Printer();
    }
    return Printer.instance;          // every call → the same object
  }

  print(job: string) { this.queue.push(job); }
}

The magic is entirely in getInstance(). The first time anyone calls it, the if is true, so it builds the printer once and saves it. Every call after that, the if is false, so it skips straight to returning the already-built instance. Ask for it a thousand times from a thousand places — you get the exact same object a thousand times.

Lazy vs eager: when is it built?

There are two common styles, and the only difference is when the single instance gets created:

• Lazy — built on the first call to getInstance() (the code above). You don't pay to create it until someone actually needs it. The catch: in a multi-threaded program, two threads could both see the if as true at once and each build one — that's the famous 'thread-safe Singleton' problem, solved with double-checked locking or a holder class (a later topic).
• Eager — built once when the class first loads, before anyone asks. Dead simple and automatically thread-safe, but you pay the creation cost up front even if it's never used.

Why the 'without' world goes wrong

If the constructor is public and everyone writes new Printer(), each call makes a fresh printer with its own empty queue. Desk A prints to its printer, Desk B prints to a different one, and now your pages are split across machines nobody agreed on. The whole point of a shared resource — one queue, one config, one log file — is lost. The prototype lets you feel this directly: create three printers, watch the jobs scatter, then flip to the Singleton world and watch them all snap onto one machine.

Use a Singleton when the thing is truly one-of-a-kind

A Singleton fits a small set of cases where having two would be a bug, and where everyone genuinely needs to talk to the same one:

• A single shared resource — one connection pool, one thread pool, one hardware device driver. Two of these fighting over the same resource causes real bugs.
• One coordinating point — a logger writing to one file, an in-memory cache, an event bus. You want every part of the app to reach the same one.
• Read-mostly global config — app settings loaded once at startup and read everywhere. (If it changes often, a Singleton's shared mutable state gets risky.)