Book 09 · Software ArchitecturePage 41 of 48

Singleton Pattern

In Turkish: Singleton Deseni

Updated September 30, 20262 min read

In short

The singleton pattern is a creational design pattern that ensures a class has only one instance and provides a single, global point of access to it.

What is the singleton pattern?

The singleton pattern guarantees that only one object of a certain class can exist in an application and gives all code a shared way to reach it. It is one of the creational patterns from the classic Gang of Four book. Typical candidates are things that naturally exist once, such as a configuration object, a logger, or a pool of database connections.

A classic implementation makes the constructor private, so no other code can call new, and adds a static method, often named getInstance(), that creates the object the first time it is called and returns the same object on every later call. In JavaScript and TypeScript, modules offer a simpler option: a module is evaluated only once, so an object exported from it is effectively a singleton for the whole application.

An analogy is a country's central bank: there is only one, and everyone who needs it goes to the same institution rather than founding their own. In multithreaded languages, singleton code must be written carefully so that two threads don't create two instances at the same moment.

The singleton is also one of the most criticized patterns, because it is essentially global state in disguise. Any code can reach it, which hides dependencies, lets unit tests leak state into each other, and makes it hard to replace the object with a fake. Many teams prefer to create a single instance at startup and pass it around with dependency injection, which keeps the one-instance benefit without the hidden coupling.

Key takeaways

A singleton class has exactly one instance with a global access point.
It is typically built with a private constructor and a static getInstance() method.
In JavaScript, an object exported from a module behaves like a singleton.
Overuse creates hidden global state that makes testing harder.
Dependency injection is a common alternative for sharing one instance.

Example

A singleton class in TypeScripttypescript

class Config {
  private static instance: Config | undefined;
  readonly apiUrl = "https://api.example.com";

  private constructor() {} // prevents "new Config()" from outside the class

  static getInstance(): Config {
    if (!Config.instance) {
      Config.instance = new Config(); // created only on first use
    }
    return Config.instance;
  }
}

console.log(Config.getInstance() === Config.getInstance()); // true

Readers ask

Why is the singleton pattern considered an anti-pattern?

Critics call it an anti-pattern because it introduces global state that any code can read or change, which hides dependencies and makes tests interfere with each other. Used sparingly for truly unique resources, it is still a practical tool.

When should you use a singleton?

Use it when exactly one instance must exist and be shared, such as a connection pool, a cache, or application-wide configuration. Even then, consider creating that single instance once and passing it in through dependency injection.

What is the difference between a singleton and a static class?

A static class only groups static methods and is never instantiated, while a singleton is a real object that can implement interfaces, hold state, and be passed around as a value. That makes a singleton easier to swap or extend than a set of static functions.