Days in the Life of Mo

There’s always that one friend.

The one who insists on being the only one. The one who shows up everywhere. The one who says, “No, no, you don’t need another one of me. I’m enough.”

In software, that friend is called a Singleton.

And honestly? It’s kind of lonely.

So… what is a Singleton?

A Singleton is a design pattern that makes sure only one instance of a class exists in your entire application, and that everyone shares it.

One database connection. One logger. One configuration manager.

Just one.

No clones. No backups. No emotional support instances.

Once it exists, it exists forever (or at least until your app shuts down). Anyone who needs it doesn’t create a new one — they’re handed the same old instance like a communal office mug everyone pretends not to notice.

This isn’t accidental. It’s intentional. Controlled. Enforced.

Which already tells you something about its personality.

Why did we even invent this thing?

Because sometimes, having more than one is chaos.

Imagine:

• Multiple loggers all writing over each other
• Several database connections fighting for resources
• Different parts of your app disagreeing on what the config values are today

That’s not flexibility, that’s a mess.

The Singleton steps in and says: Relax. I’ve got this.

One source of truth. One shared state. One place to look when something breaks.

In theory, it’s comforting.

Why is it… lonely though?

Because everything depends on it.

Everywhere you go in the codebase, there it is. Always available. Always reused. Never replaced.

You don’t inject it. You don’t question it. You just… reach for it.

And that’s where things get awkward.

The Singleton knows too much. It sticks around too long. It gets blamed when things go wrong.

And testing it? Emotional damage.

Because when something exists globally, isolating it becomes hard. Mocking it feels unnatural. Resetting it between tests feels like erasing memories.

It’s not just a pattern anymore, it’s a lifestyle choice.

The dark side no one warns you about

Singletons look harmless. Elegant, even.

But over time, they start to:

• Hide dependencies (“Surprise! This class secretly relies on me.”)
• Make code harder to test
• Create tight coupling between things that should mind their own business

Suddenly your app feels less like a well-organized system and more like a group chat where everyone refuses to leave.

This is why you’ll hear experienced devs say things like:

“Singletons are basically global variables in a trench coat.”

Harsh. But not entirely wrong.

Are Singletons bad?

No.

But they are powerful, and powerful things require self-control.

They make sense when:

• You truly need a single shared resource
• Creating multiple instances would be expensive or dangerous
• The state is well-defined and predictable

They become a problem when:

• They’re used out of convenience
• They creep into places they don’t belong
• They become the solution to every design problem

Just because you can make something a Singleton doesn’t mean you should.

(Somewhere, a Dependency Injection container just nodded.)

A quick reality check

If you find yourself saying:

“It’s easier if I just make this a Singleton.”

Pause.

Is it easier… or are you tired?

(Valid, by the way. We’re all tired.)

But sometimes the better choice is passing dependencies explicitly, even if it feels verbose. Even if it feels less magical.

Magic is fun. Maintainability lasts longer.

---

Have you ever worked on a project where everything was a Singleton?

Or worse, been personally victimized by one during testing?

Tell me. I want the tea.

---

Want more posts like this?

If you enjoy tech explained like a conversation and not a lecture, stick around.

Subscribe to the blog for thoughtful dev stories, everyday coding lessons, and the occasional rant from a developer who loves building things but questions everything while doing it.

No spam. Just words, code, and curiosity.