Singleton

The Singleton pattern makes sure there is only ever one of something — like the one TV remote a whole house shares. Ask for it a hundred times and you get the same one back, never a second. That is handy when a program needs a single shared thing everyone agrees on: one settings box, one logger, one place that hands out database connections. Here is the Singleton pattern explained simply — the idea first in plain words, then the real code once it clicks.

What is it

A Singleton makes sure there is only ever one copy of a thing, and it hands that same copy to everyone who asks. Picture the family TV remote. There is exactly one, it lives on the same couch, and whoever wants it reaches for that same remote — nobody runs out to buy a second. The first time your program asks for the Singleton, it builds the one copy. Every ask after that gets handed the copy that already exists.

How it works

The class keeps its one copy tucked away inside itself and refuses to let anyone make another. Normally you can create as many copies of a thing as you like. A Singleton quietly closes that door. The only way in is to ask the class, and the class decides: build the copy the first time, or hand back the one it already built every time after. Because everyone comes through that same single door, everyone ends up holding the exact same thing. Change it in one spot and everyone sees the change, because there is nothing else to change.

When to use

Reach for a Singleton when the whole program must agree on one shared thing. One settings box that every screen reads from. One logger writing to one file, so the lines never get jumbled together. One pool handing out database connections, so you do not accidentally open a thousand. The clue is the word one — if a second copy would cause confusion or waste, a Singleton keeps everyone honest. You have met it without knowing: the one settings object your whole app reads, a game's single audio manager, the one clock every part of the screen checks.

Watch out for

The catch is that a Singleton is a shared global thing wearing a polite disguise, and shared globals cause quiet trouble. Any corner of the program can reach in and change it, so a bug over here can surprise something way over there. Tests get harder too, because every test secretly shares the same copy — one test can leave it in a state that trips the next. It is also the most overused pattern of all. People reach for it because it feels tidy, when a plain value passed in by hand — or a Factory that builds a fresh copy each time — would have been clearer. Use it when there truly must be one, not just because one is convenient.

In real code

One shared settings box the whole app reads from.

class Config:
    private static instance = null
    private constructor()          # no one else can build one

    static get():
        if instance is null:
            instance = new Config()    # built once, on first ask
        return instance                # same object every time after

Every caller gets the exact same Config object.

public class Config {
    private static Config instance;
    private Config() { }              // private: nobody outside can 'new' it

    public static Config get() {
        if (instance == null) {
            instance = new Config();  // created once, lazily
        }
        return instance;             // same instance for everyone
    }
}

Analogy

The family TV remote. There is exactly one, it lives on the same couch, and everyone uses that same remote. You cannot buy a second, and when someone changes the channel, everyone is now watching the new channel — because there is only ever the one.

▸ practicePractice lessons

Lessons coming soon.