Yet another post on Singletons

Im doing the Unity Turn Based Strategy course, and I know we have used some singletons, probably lots of them, depending on who you ask.

I have already read this article What is the issue with Singletons? And im not here to ask the same.

These are my questions:

  1. What are the pros/cons of using a Singleton vs some other aproaches.
  2. What are those other possible aproaches in Unity? What other patterns or coding styles in general could I use, if I want to avoid Singletons?
  3. Most importantly: What questions should I ask myself about the code or functionality, before deciding if a Singleton is or not the best aproach in this case?

If anyone would provide me with some simple examples that would be perfect, but its not neccesary.

Im not fully againt nor fully in favour of Singletons, I just want to understand which are and are not the use cases.

Thanks :smiley:

I would have expected the subject on singletons to be limited to one thread…

alas…

It depends on the other approach. It’s hard to compare one without the other. I’d say they’re different, depending on the pattern you’re comparing it to :wink:

There are heaps.

While I don’t want to sound vague, if you want to avoid singletons, you literally have access to every pattern that isn’t called Singleton.

It’s really as simple as, “What tool that I know would best help me solve this problem.”

These patterns are just common solutions to problems that tend to pop up time and time again. A singleton is just one of them. For me, it’s good when you want a piece(s) of functionality or set(s) of data that is required to be handled/controlled by a central place.

A Pause Manager is a good example. In a game, what you don’t want is multiple objects trying to fight over control of when time stands still. This can lead to unpredictable outcomes or difficult to debug gameplay.

In itself, a singleton isn’t a bad pattern. It gets a bad wrap with new programmers coding themselves into the proverbial corner with cyclical dependencies, tight coupling and low cohesion. They’re just things you learn to code with as you gain experience.

I wouldn’t expect the issue of singletons to be settled once and for all in our lifetime…

Pros

  • Ensures one and only one instance
  • Provides easy static access to this instance, avoiding the need to FindObjectOfType or FindWithTag

Cons

  • Represents a global state in an Object Oriented environment
  • Easy to lose control over access to the Singleton

Here are the three most obvious:

  • Serialized fields, for instance, dragging the UnitActionSystem into a field in design time, for example
  • FindObjectOfType or FindWithTag
  • Dependency Injection: Passing the class instance to an Instantiated class at runtime by a class that already has a reference to the system.
  • Does this class have to be unique?
  • What is preventing me from linking to the class directly from the objects that need it?
  • Are there any unintended side effects to using a Singleton here?

Remember, it’s a tool. Nothing more, nothing less.

Privacy & Terms