Is it bad form to use singletons in unity [closed]

Question

I've heard a lot of people say singletons are bad practice and an 'anti-pattern', like here, this answer this article and here. However, a lot of the reasons I've read about seem to be to do with dangers in their creation, them not being thread safe, difficult to destroy safely etc. But in unity where there are functions such as awake() and start() which are (as far as I'm aware) guaranteed to only be called once, are they unsafe to use?

Answer 1

You have stumbled onto a controversial topic in the programming world. Most people dislike singletons, but we game developers tend to be a bit more friendly towards them. There are pros and cons to singletons.

My answer is specific to Unity, and covers maybe 1% of the topic.

In Unity, Singletons are very useful. Let's say you have a manager class that you want to be globally accessible. You could make a static class instead - but then you lose access to Unity messages, Awake, Start, Update, etc., which are the heart of MonoBehaviours.

You mentioned thread safety - Unity is single threaded. So you will not run into these problems (unless you explicitly break off the main thread).

So why are they so bad? There are much better articles, like the ones you linked, which explain it much better than I can.

But if you stay disciplined, Singletons can make game development much easier. However, since you don't have any of the safeguards that you gain with other design patterns, it is easy to fall into the traps that Singletons present.

Answer 2

Awake() and Start() are called only once per object for reasons unrelated to Singletons. The single instance part of the singleton is fine, and its possible to make it thread safe and control how many things its keeping in memory because it never dies. It's the global accessibility that a lot of design pattern people dislike. Having a singleton in your code won't break it, but using them for everything can cause problems. Take it from someone who built a prototype held together by a half dozen singletons. I would slap that version of me if I could.

In large projects, it is important to 'decouple' your code. Overuse of Singletons promotes coupling code together. An example is a having an AudioSingleton that plays sounds. It looks like an awesome idea because then you can simple call AudioSingleton.Instance.PlaySound(GUNSHOT1); in your weapon code, and you're done. That's actually a huge problem. Now your weapons depend on the existence and functionality of the AudioSingleton.

It gets worse as the project grows, and the team grows. Every button press is a series of calls to different singletons, or one call to a massive singleton that sits at the center of your project, immovable and instable. Singletons lash together disparate objects and make it easier to cause problems and make finding problems more difficult.

There is a time and place for Singletons, but you need to be careful that you aren't solving a problem that just needs some carefully laid out wires and some solder with a global communications network. If you can avoid using a singleton by using something like the Observer pattern, you almost always should.

Also, even when you are working alone, your "team" grows over time, because you forget what you were thinking when you wrote your old code. In the years of solo development I've learned one thing: if you don't want to hate yourself write code like you're in a team.

I'd suggest reading this book: https://gameprogrammingpatterns.com/contents.html It put labels on all the patterns I blindly trying to use and explained their pros and cons with good examples.