Prateek Prabhakar

Posted on Jul 21 • Edited on Aug 27 • Originally published at Medium

Design Patterns Simplified: Part 6 – Singleton Pattern (a.k.a. “One and Only One”)

#designpatterns #softwareengineering #techinterview #cleancode

Singleton Pattern belongs to the Creational category of design patterns.

Why? Because it focuses on controlling how objects are created, specifically ensuring that only one instance of a class exists across your entire application.

When it comes to interviews, this is one pattern most of us are fairly comfortable with because the name itself speaks loud for what it does!

The Problem: Too Many Instances

Suppose you are building a backend service that needs to connect to a database to store and retrieve data for the UI.

Do you create a new connection object every time?
Or more importantly, do you even need to?

The answer is a clear NO. Spawning multiple connections would be resource heavy and error prone. You would eventually exhaust connections and crash your app.

What is a better approach?
Create a single, shared instance of your database connection and reuse it across your service. Because all you need is one shared access point to the database.

What is the Singleton Pattern?

It is a design pattern that ensures a class has only one instance and provides a global point of access to it. It restricts object creation and lets you manage shared resources efficiently.

Another Example: The Logger Problem

Imagine you have a simple Logger class,

// Without Singleton
Class Logger
    Method Log(message)
        Print(message)

If every module creates its own logger instance, you’ll end up with inconsistent logs or even duplicate file writes.
What you actually need is one global logger instance for your entire app.

The Solution: Singleton Pattern

// Singleton Implementation
Class Logger
    Static Instance = null

    Private Constructor()  // Prevent external creation

    Static Method GetInstance()
        If Instance == null
            Instance = new Logger()
        Return Instance

    Method Log(message)
        Print("LOG: " + message)

//caller logic
logger1 = Logger.GetInstance()
logger1.Log("Application started.")

logger2 = Logger.GetInstance()
logger2.Log("User logged in.")

// Here logger1 and logger2 are actually the same instance!

What Did We Achieve?

One and only one instance across the app
Global access via GetInstance()
Controlled resource usage
Prevented accidental multiple instances

When Should You Use Singleton Pattern?

Need a single coordination point (e.g. config managers, loggers)
Managing shared resources (databases, filesystems)
Avoiding unnecessary object creation in stateless services

Use Cases?

Database connection manager
Configuration settings
Logging service
Caching layer
Thread pool manager
File system handler

One Important Caveat

Singleton provides global access, but overusing it can lead to tight coupling and hidden dependencies.
Use it wisely, only for truly shared, single instance resources.

To summarize, it would be apt to say,

Singleton Pattern ensures only one instance of a class exists and provides a controlled, global access point to it.

It is simple yet powerful. When used correctly, it keeps your application efficient, organized, and resource friendly.

Next up in the series: Builder Pattern. Come over to read about it...

DEV Community