Purpose of singletons

[-]

Ill-Significance4975@reddit

The best explanation I've ever seen--

Singleton is just politically-corrrect global variable(s)

There are very, very limited cases where global variables are the right answer, but-- it does, sometimes, come up. If you're committed to disallowing global variables because its 1997 and that's a bad idea we're still dealing with, it makes sense to mandate a new idiom.

In 2026? Prove me wrong in the comments below. Seriously, I'm genuinely looking for a decent counteragument.

[-]

iOSCaleb@reddit

You’re exactly right, except for the politically correct part. Using a singleton instead of a global variable is like wearing a domino mask to an orgy: you’re not really hiding anything.

The Singleton pattern is meant for cases where there must never be more than one instance of a class. Because of that restriction, singletons are always shared objects, and that’s where the trouble starts. That shared instance is globally accessible, so it has all the same problems that global variables do: the shared object can be accessed and modified from anywhere; shared state complicates reuse and testing; etc. Lots and lots has been written on this topic.

The main thing to know is that programmers who create singletons are destined to spend eternity in a room in The Bad Place filled with bees with teeth.

[-]

Great-Gecko@reddit

Ideally, mutable state should only exist in the database. State in a singleton sounds like a disaster waiting to happen.

[-]

Ill-Significance4975@reddit

A screenbuffer about to be blitted is a classic counterexample to The Database, but you kids these days and your web everything.

[-]

Great-Gecko@reddit

Yeah I should've been a bit less absolutist in my statement. In performance-critical code, mutation is preferable. We should just be highly intentional about where mutation occurs.

[-]

JGhostThing@reddit

For example, if I am making a webapp to design starships, I want a list of created ships. There must be only a single such list. So I could define this as a singleton.

[-]

Great-Gecko@reddit

IMO it's a pretty useless pattern. Particularly considering most Java devs use a dependency injection framework (eg. Spring). Injecting qualified beans is a much better approach than the classic singleton approach. A large (\~10 000 classes) codebase and we rarely use the singleton pattern as its classically described (ie. private construcor + static accessor).

I could, however, imagine it being used more frequently when a DI framework isn't in play, but then it'd still be preferable to manually handle your own wiring.

[-]

DTux5249@reddit

A singleton serves 2 purposes:

1) Ensure there's only 1 instance of a class.

2) Ensure that instance is accessible from anywhere.

As for why that's different to a static class? 3 big things

1) You can subclasses of a singleton.

2) A singleton can implement interfaces.

3) A singleton is an instance: i.e. you can pass it into other methods as a parameter, and treat it like a normal object.

[-]

s00wi@reddit

Can you provide an example of both a singleton and a static class. And point out the structural differences?

[-]

DTux5249@reddit

Basic Singleton would be something like this:

public class Singleton {

    // private static instance & constructor
    private static Singleton instance;
    private Singleton() {}

    /*
    other private variables the class has 
    */

    // function that retrieves the instance
    public static Singleton getInstance() {
        if (instance == null) instance = new Singleton();
        return instance;
    }

    /* 
    any other functions you might have
    */
}

To use singleton functions you basically just go:

// using some function; you can just grab the instance however and use as you will.
Singleton.getInstance().foo();

// passing singleton in as a parameter; often preferred over getInstance() directly
otherClass.randomFunction(Singleton.getInstance());

Static class meanwhile:

public static class StaticClass {
    // all static variables 
    private static int foo;

    // maybe getters / setters
    public static int getFoo() => return foo;
    public static void setFoo(int newFoo) => foo = newFoo;

    // some random static functions that do stuff
    public static void bar(){
        // logic...
    }
}

Using this similar to the above,

// using some function
StaticClass.getFoo();

// you can't pass this around as a parameter tho. Nothing like:
// bar.randomFunction(StaticClass)

[-]

JayDeesus@reddit (OP)

I’ve seen the term dependency injection used a lot. What exactly is that?

So the benefit of a singleton is that it can be passed around whereas a static class can’t be, but if a singleton guarantees a single instance then in the class that you would pass the singleton into it can be done with a static class by just calling the static class inside of the method no?

[-]

binarycow@reddit

The gist of dependency injection is to have other people give you things, rather than you create it yourself.

[-]

DTux5249@reddit

I’ve seen the term dependency injection used a lot. What exactly is that?

A "dependency" is something your code needs to work in order to do its job. If I have a "Round" object that manages two "Player" objects in turn-based strategy game, Round depends on the Player class having certain behaviors. At first it may seem simple to have Round create its players when it's created. But say if, instead of having multiplayer, I want to be able to play against an AI. If I wanna add or change that behaviour to compensate, I'd have to add a bunch of checks to Round in order to make it work with the new AI player; have it ask "are we playing X game or Y game?" and instantiate an AI or a player controller depending. And what if I want two AIs? Or something else? I'd have to edit Round 5 different ways to Sunday every time I wanna change the underlying implementations of the players, or how they work.

Dependency injection is the idea that dependencies should be "injected" into a context instead of that context creating its own; that the context should rely on an abstraction (an interface) instead of any specific concrete class in order to work. Round shouldn't create its players - it should be handed them; generally when it's constructed. In context, this would be having my Round class' initializer taking two IPlayer parameters; with both HumanPlayer, and AIPlayer being two different implementations/subclasses of IPlayer. That way, Round doesn't have to care whether its players are human, AI, or maybe even a tester class with some data I set up, or something else entirely in order to do its job. If I make a new type of player, I just pass that player into Round, and it works still - no editing required. It just asks "who are my players," and goes on its merry way once you give them to it.

Using a static class doesn't allow this. So if you wanna have your code rely on something other than that specific static class, you have to add a bunch of if-else statements going "am I using this static class? What about this one? What about this one?" That's very prone to errors, especially if you have to go back to add more ifs everytime you have a new type of dependency.

It's not about "does it work"; it's about "how manageable will this be in the long run?"

[-]

cbentson@reddit

Singletons are great when you want everything in your app to use the same “shared” thing.

A good real world example is an office with a printer. Everyone in the office shares the printer. You don’t buy a new printer every time someone needs to print something.

A good example of singleton in software is a database connection manager. You really only want one thing managing your database connections.

[-]

JayDeesus@reddit (OP)

What about a static printer? A single printer shared as well no?

[-]

DrShocker@reddit

Idk if that's the greatest example. Just because something isn't a 1:1 relationship isn't enough justification imo. You may find the drafters need the big printer and the lawyers the fast printer and other groups need different chariteristics, so having literally 1 printer for the whole office is needlessly restrictive to getting access to the printers with the right qualities for each person's needs.

[-]

flamingspew@reddit

I use it for game state. I don‘t ever want multiple copies of game state. Your Printer analogy is wrong. I want one lookup diagram for the IP address of every printer. That diagram can have each type of printer stored in it.

[-]

DrShocker@reddit

Honestly I don't have enough experience with games to say one way or the other. I think if I wanted to be able to test stuff about many game instances simultaneously, I might be annoyed if it were a singleton, but I also don't know that it's a useful thing for me to think about in a game.

[-]

flamingspew@reddit

What are you talking about? In my example it’s just s state machine like a redux reducer or whatever. You’d never want more than one instance state.

Gamestate - levelstate - playerstate - menustate

Etc

MVC or similar conceptual framework.

[-]

DrShocker@reddit

I could be wanting tweak jump height or something and see what happens for 10 different values simultaneously. Or be writing tests that ensure certain inputs continue to solve important levels all simultaneously. Or be trying to explore state space for things to break, so need to run as many copies as possible headless.

Singletons just almost always end up limiting the options in my experience rather than enable options.

[-]

flamingspew@reddit

Nothing stopping you from making test instances of each singleton state reference. Something like jump height would have nothing to with game state. State is like „what level am i on?“ „which menu is open?“ „how much ammo do i have?“ „which level is being unloaded right now?“ you never want more than one source of truth for this.

[-]

DrShocker@reddit

It's definitly possible I've just been burned too much by people using singletons. In the code I work on now there are often tests that I'd like to add, but first I need to rip out the references to a singleton so that the state doesn't get fucked with by other parts of the code implicitly. (particularly this is one of the reasons we can't yet run the tests all in parallel)

I 100% agree that having more than 1 source of truth for those kinds of things is a pain in the butt and should be avoided, but I'd still say most of the time the "singleton" should just be the argument to the function. That way it's clearly shown in the code that the function relies on the state of the "singleton" and it can specify if it's const or not if the language supports that kind of thing. (looking at you, python).

The issue I see with something like "is the game paused" being in a global singleton is that it becomes too easy for people to throw in a `state.pause()` somewhere, and for checks to be at random points, which overall could lead to unforseen interactions between state changes and state checks compared to being more rigorous about it. If you're disciplined about it though, then yeah it's convenient.

Web apps, and in particular databases are an interesting case. They put a ton of effort into making their apparent state consistent usually, but at the same time we have issues like the "two generals problem" which make fully deterministic communication in a distributed network unsolveable on some level.

[-]

flamingspew@reddit

Thats what the state reducer pattern is for. State is immutable from the outside, you have actions or events that mutate state with mutation validation.

In a game i might dispatch +10 points event from a level directly, or from character‘s combo engine. The state manager will do the running tally calculation. No view can alter state directly.

[-]

DrShocker@reddit

Sure, and that keeps interactions happening at controlled boundary points. (which is great because I've worked on stuff where people put zero thought into how changing values at arbitrary times could fuck up the state. Never assume things are implemented well when you're working on other people's code ☠️)

I just don't think singletons have much to do with implementing that either way.

[-]

flamingspew@reddit

It‘s literally the only way to do it properly for global state. You can’t have event listeners all over the place. Redux IS a singleton and requires pure functions to mutate it.

I don’t really care about people doing their own antipatterns with a concept. That isn‘t a slight on the concept, that‘s a skills issue.

[-]

glemnar@reddit

Sorry, are you contesting their perfectly reasonable metaphor with unnecessary contrived examples?

[-]

DrShocker@reddit

IMO examples of singletons need to be careful because it's easy to abuse them and create a rat's nest of entanled dependencies that aren't clearly expressed. The printer example would lead to challenging to change or test code in my experience.

I think honestly it's quite rare to think of simple situations that are actually best solved by singletons because it makes it easy to hide dependencies and increases coupling. If I had to think of something to use as an example it would be something like a Supreme Court. They are the highest court in the land, and while having many state courts or smaller jurisdiction might be reasonable, there's intrinsically no reason to add a court above or equal to the supreme court because it'd just contradict the definition of a supreme court and create unresolvable conflicts.

[-]

robhanz@reddit

The other alternative is dependency injection. "Shared" isn't a great reason to use a singleton - enforced single instance is.

While you don't necessarily want every object creating its own database connection manager, there are many cases where you actually do want two connection managers.

[-]

dkarlovi@reddit

Until you have two database connections because you're migrating the data and doing double writes.

[-]

robhanz@reddit

So there's two real uses for singletons. First is to have a single, shared instance without using dependency injection. This is honestly the version that gets flak.

A better use case would be to look at Smalltalk. In Smalltalk, everything is an object. True and False are objects. Since all True and False objects are equivalent, there's no need to create a billion of them. Instead, having single, well-known instances of them makes a lot of sense. Same with String.Empty in C#.

Java doesn't do String.Empty, but it does the equivalent under the hood - every instance of an empty string points at the same object internally. So it's internally using a singleton, it just hides it from the user.

[-]

dnult@reddit

One use for singletons might be a channel for passing messages to a device. You have a single channel connected to a single device and a program that needs access to it from multiple places within the code. The Singleton pattern ensures the channel gets instantiated and initialized on first use, but every other time that channel is accessed through the Singleton pattern gets a reference to the same object. It's not a very widely used pattern but it is perfect for some cases like this.

[-]

balefrost@reddit

One place where singletons make a lot of sense is when multiple instances of the same class are equivalent. In cases like that, there's no benefit to instantiating the class multiple times - doing so would just use more memory and put more pressure on the garbage collector.

A concrete example: suppose you have some custom Java type called ComplexType. You want to be able to sort a List<ComplexType>, so you define a class ComplexTypeComparator that implements Comparator<ComplexType>. The comparator class is stateless - it has no mutable fields - so two instances of the comparator class are essentially entirely equivalent. In this case, it might make sense to make ComplexTypeComparator a singleton.

As other people have mentioned, people do abuse singletons. Singletons are essentially global variables and come with all the same caveats. They make it easy for a function to get access to services that it might need, but they obscure that data flow. They bake structural assumptions throughout the code base, making future refactorings harder. Stateless singletons mostly avoid those problems, which is why stateless singletons are generally fine.

[-]

Express-Channel-1686@reddit

singletons are useful when you genuinely need one instance — database connections, config loaders, logging. the anti-pattern trap is using them as global state just because it's convenient. if you're routing data through a singleton to avoid passing arguments around, that's a code smell worth fixing.

[-]

PvtRoom@reddit

say you create a GUI for input to your code.

how many instances of the gui do you want? 1. you want a singleton.

how many usb handlers for your usb dongle (proof of licence)? 1.

[-]

Life-Selection6377@reddit

I used to think the exact same thing when I started. If you just want to access some utility methods, a static class is fine. But a singleton is an actual object, and that changes everything in a real project.

Think of it this way,

- Interface and Inheritance

You can't make a static class implement an Interface. If you have a DatabaseConnector singleton, it can implement a IConnector interface. This is huge for testing and keeping your code flexible.

- State Management

A singleton is better for managing complex state. If you need to pass that single instance around to other methods or objects as a parameter, you can’t do that with a static class because there's no instance to pass.

- Lazy Loading

With a singleton, you can control exactly when that object gets created. A static class gets loaded as soon as the JVM touches it, but a singleton can wait until the very moment you actually need it (saving memory and resources).

basically, if it’s just a bunch of math functions, go static. If it’s something that represents a service or a resource like a Logger or a DB pool that needs to behave like an object, go singleton. It took me a few dependency injection headaches to finally realize why everyone makes a big deal out of it

[-]

m0rcen@reddit

It’s close, but not the same thing, and that difference matters more than it looks at first glance.

A static class is like a toolbox nailed to the wall. Everything is global, there is no instance, and you cannot treat it like a real object. A Singleton, on the other hand, is still an object, you simply make sure there is only one of it. That means you can pass it around, implement interfaces, swap it in tests, and plug it into dependency injection. You keep all the benefits of OOP while controlling how many instances exist.

Think about an airport with a single air traffic control tower. All planes, whether landing or taking off, talk to the same control tower. You do not spin up a new tower per plane. If you did, you would end up with chaos, conflicting instructions, and unsafe conditions. The whole system works because there is exactly one authority coordinating everything in real time.

If you make everything static, it becomes hard to test, hard to replace, and tightly coupled to everything that touches it. A Singleton gives you a single shared instance, but it still plays nicely with the rest of your design.

So yes, both end up with “one shared thing,” but they get there in different ways. Static removes the object entirely. Singleton keeps the object and puts a fence around how many exist. That small distinction ends up doing a lot of heavy lifting once your codebase grows.

[-]

Extramrdo@reddit

Additionally, so you can have zero of the thing. If you have to do anything with states or variables, using only a static class, every method has to ensure that the class has been set up and is still in a valid state. With a Singleton, you can't call methods on something that doesn't exist yet.

[-]

hanato_06@reddit

A singleton is "SINGLE". You're designing something that's only ever meant to exist once in the program.

In video games, you can define a GameManager class responsible for orchestrating the loading, saving, game state updates, etc etc...

Great, but should you allow the ability to make multiple instances of this GameManager? What if, down the line, you accidentally create some weird bug where you create two instances of a GameManager, and the player tries to save? What if your co-worker accidentally instantiated one instead of getting the one from your static definition?

By making it a singleton, you guarantee that the constructor cannot be used to make more of what already exists, and the same instance is used everywhere.

[-]

AdministrativeLeg14@reddit

You could use a non-singleton class with only static properties, I suppose. It would be functionally similar to the singleton. But let’s think of the pros and cons. Cons first:

It’s conceptually less straightforward. A singleton object maps onto real world concepts: There’s only one X, so everyone has access to the same X. Non-singleton objects without state don’t make any sense to me: They don’t represent anything. What’s an X?
It would, in straightforward implementation, be slightly less efficient. If you have objects sharing static state, then every caller that wants an object still has to allocate one on the heap—there are more objects around, so they take more time to allocate and use up memory.

But although it would be less efficient and more confusing, let’s consider the pros:

…

…Yeah, I’ve got nothing.

[-]

mxldevs@reddit

A class with only static methods isn't enough to qualify as a singleton. For example the Math class that provides static methods for finding the abs or performing round wouldn't be a singleton.

A singleton is an object that gets instantiated exactly once for the lifetime of the application, because you want there to only be one instance of it.

It can be implemented in a class that provides static methods to work with it, where the static methods are operating on an instance of the class that is stored privately and therefore every component that calls on it would be working with the same instance.

This could be used for the sake of convenience which is sometimes just being lazy. Perhaps it leads to more efficient use of resources. Or perhaps there could be actual requirements that you can't have more than one instance of the object, and so now you can make sure all operations must go through your interface.

[-]

Marthy_Mc_Fly@reddit

The purpous of a singleton is to have one global object. If you'd have a normal class with just statics, everyone could create a new object of that class. Also for example interfaces loose most of their value. Because static methods work with the class not instance. And interfaces work with instances not classes. So you polymorphism won't work properly.

[-]

Dus1988@reddit

Stateful vs stateless is kinda a dividing line. Plus instantiation is different.

I.e. static class, it's eagerly instantiated. A Singleton is lazyily instantiated, so if nothing is using it, it's not taking up mem. Plus the Singleton fn usually has some kind of pointer to a instance and a factory fn to create the instance, if not needed

Also, you can have truly immutable consts in a static class, but you should not be using a static class for mutable state. An AppConstants class for instance could make sense but you don't want a ApiConnector to be just static. It needs to manage the active connection to the API or DB, without making new connections on each call

[-]

Logical_Angle2935@reddit

At least one advantage over a class with all static methods is you have a constructor and destructor (RAII) if needed.

You can also control access to it, for example if it can only be constructed by one other owning class. This can improve design and promotes single responsibility principle.

[-]

Business-Row-478@reddit

Using fully static classes are a bit of an anti pattern if they store any state. So they are ok to be used for things like pure functions, constants, etc.

But if you want to use the class for anything stateful, such as database connections, services, etc you don’t really wanna be using static classes.

Singleton instances are more flexible and allow lazy loading, inheritance, mocking for testing, garbage collection, dependency injection, etc.

[-]

rooygbiv70@reddit

If the class is written with the intent that it must be a singleton, why not have the class encapsulate that constraint and manage the single instance? Otherwise, you are placing the trust on the code that uses the class to not create redundant instances.

[-]

Far_Nectarine_984@reddit

The main difference is that singleton gives you actual object instance that you can pass around to other methods or classes while static class is just... static. Like if you have database connection singleton you can inject it into different services but with static approach every class needs to know about that specific static class name

Also singletons can implement interfaces and extend other classes which static members cant do. Plus lazy initialization is cleaner with singleton pattern

[-]

polymorphicshade@reddit

Search for "best use cases for singletons" or "singleton pros and cons" on Google and see what you can learn 👍