I have the tendency to overuse singletons...

Hello people!

In recent years, I have acquired the addiction of using too much Singletons in my projects. All the managers that I project have already started to create a Singleton...

Now I ask myself the question: is this healthy?

Do you often use many Singletons in your projects?

 

Is it working fine?

 

So you have a megaton of singleton?

 

This is the most important question, followed immediately by "Is it maintainable?"

You can spend a ton of time writing "correct" code, that complies with every "best practice" and recommended pattern and style guide ever written. Or you could actually get your game made in under a decade. I suspect it would be very difficult to do both.

PS - I use singleton managers all the freaking time.

 

Hi, I'm orb and I'm a singleton addict. I can manage it. I made a singleton to manage my singletons…

 

Singletons are often the best way to do something, especially manager classes.

 

I know people seem to despise Singletons, but you do need different classes able to communicate with each other. It almost seems unavoidable, but I would love to hear how you can build a game of any sort of complexity without at least one globally available object.

 

are they causing problems for you? i tend to have 2 or 3 singletons in each project, and often will use my main game manager singleton as a entry point for something similar to the service locator pattern.

as long as its manageable for you just stick to it, if its not manageable look into what you can do to improve things.

I also make pretty heavy use of creating things that dont need to exist in the scene as a ScriptableObject and dragging it reference into anything that needs it, or referencing all of these objects from one singleton and having a method for finding the instance based on a generic type parameter.

 

Using singletons itself is not a problem, using them when it's not necessary could be one.

If some object is conceptually required to be unique in its existence, then actually prohibiting multiple instantiation of the class by using singleton pattern could be even considered as a best practice.

But if you find yourself relying on the pattern, simply because it's easier to obtain references that way, then probably it's time to find out what other options there are, like turning some of them into ScriptableObjects where appropriate, or refactoring your code to introduce some type of class that act as a context or service locator that holds references to other crucial services, or considering to introduce a DI(dependency injection) container like Zenject (personally, I found it to be very powerful and quite easy to use).

 

Are there any moments where you spend hours dealing with a problem and at the end of it think 'I wish I hadn't used a singleton here'?

I used to use singletons a lot, and had a lot of those moments. Now I tend to avoid them like the plauge. If you aren't having those moments, then you probably don't need to change your architecture. But if you do game design on the fly as you write code, singletons will be the bane of your existence.

I would rephase that one to "How much time do I actually spend maintaining it?"

Maintainable code is good, if you actually do code maintenance. If you never do maintenance, you've just wasted your time writing maintainable code.

 

https://stackoverflow.com/questions/137975/what-is-so-bad-about-singletons gives some of the basics.

Using good design does not inherently take more time. It will very quickly save you time.

But more to the context of unity. Most of what people use singletons for is wrong. There are cases where you need them. Usually in the context of retaining instances dealing with IO. Sometimes unity's own limitations mean you need to cache stuff to avoid reloading it between scenes. But you should never expose that publicly. So even if you actually need a singleton, you don't need a public singleton.

Dependency injection can help here, but just saying use dependency injection still doesn't tell you ok how do I handle stuff that needs to persist for the life of the game.

The answer to that is usually a singleton of some type. But again it's not public. The approach I prefer is to to use lazy caching. You can just call methods to set everything, or you can have the internal logic manage that automatically, by loading stuff as it's called for and caching it if needed.

You can certainly use something like Zenject, but it's not necessary. You can start out here simply by just creating base classes that derive from monobehavior. Lazy caching helps here because that way your base class doesn't need to use Start/Awake. These base classes can provide protected methods to access what you were originally providing via singletons. As your project grows you can add more feature specific base classes.

 

If it's something you only use on one scene... don't use a static class (necessarily) because that memory never gets freed up. Other than that Singletons in general are fine. They are hard to test and they sometimes make it hard to know where an error originated from but they're not evil.

If I had one suggestion, it would be to use a static class as a lightweight container to house your managers if you're using static at all. The manager itself can be a regular class. The static class can have a property with a private set and the static constructor can set that property to an instance of your manager, that way it only happens once. You still only work with a single instance of your manager and it's still a Singleton, but not static. That allows you to implement interfaces with your managers.

I don't know if you're using static classes at all or just basically the Singleton pattern for Monobehaviours but it's something to keep in mind.

 

The main benefit of using a DI container like Zenject in this context, could be that with such a framework, you can manage lifecycle of your components in a declarative manner.

Of course, it's not the only way to solve the potential problem of singletons, but being able to just declare "this service should be persist through the game" is quite a neat feature.

Actually, if I remember correctly, DI containers became popular once it began to be used as a replacement for Service Locator pattern in enterprise applications, which is specifically designed to mitigate (somewhat insufficiently) the shortcomings of using singletons.

 

When your projects drag on as long as mine do, "development" and "maintenance" are pretty much the same thing.

 

I see writing a maintainable code to be more of a habit than of an investment.

It's not unlike the use of Prefabs, in my opinion. Those who just started to learn Unity might fail to grasp the benefit of using them, or having difficulty learning how to create or instantiate them. And if a project already has thousands of duplicated game objects, it might not worth the cost of replacing them all with Prefabs.

However that doesn't mean that one shouldn't bother learning how to use a Prefab until one is involved in a project with a lot of maintenance tasks.

As you know, creating a Prefab doesn't incur too much overhead once you understand the concept and get accustomed to work with them. And its long term benefits probably far outweigh the cost involved in learning it for the first time.

And I believe the same can be said of various best practices regarding writing maintainable code. One might find it less intuitive to read and write code using the Factory pattern, for instance, compared to just using a long series of if-else statements. And probably the cost of refactoring an existing codebase to replace every such conditional statements would be prohibitive, if the project is large.

But like Prefabs, once you understand the concept of Factory pattern and get accustomed to use it, you would start using them as easily you would use plain if-else statements. The only difference would be you'll begin to see people who haven't experienced the same process complain that your code is 'too complex'.

Probably it's just a matter of a trade off between keeping your codebase clean, and making it accessible to other developers in your team, if they have widely varying degrees of experience.

 

I would define it further as just a way of writing code. Code maintenance and large refactors is not something I even do anymore. Unless I just completely missed something and didn't catch it until much later, but with experience that happens less and less.

What I do is I spend probably 10% of my day making small refactors. If I touch a piece of code I leave it better then when I started. Sometimes I have to stop and do an hour or so of work, because maybe what I want to add pushed it over a line.

The thing is it's a chicken and egg problem here. You won't do it until you get to the point where you understand the benefits. And you won't understand that without doing. The best way to overcome this is to get on a team with great developers and work beside them. I learned more doing that then anything else I can point to. Working beside people that write good code, if you have any ego at all, makes you a better developer faster then anything else.

 

There is a high correlation between people who hate singletons and people who have used singletons stupidly. Just about every time I've ever heard someone rail against singletons, they have a story that usually boils down to using a singleton in a situation where it never belonged or expanding onto a singleton past the point where it made sense.

They are very context sensitive, which flies in the face of maintainability that wants code to be context agnostic. Then it's also good to stress KISS and single responsibility. They should serve one straightforward function, and any modification should require re-evaluating everything about them.

 

I think we are approaching the same concept from different angles. There are some aspects of 'good' code that I know will pay off. I do these all the time pretty much by default. There are a few other aspects of 'good' code that I know will lead to me doing more work for no benefit, so I tend not to do them.

I'm not entirely sure of this. Any programmer can easily recognize the point where code is causing them problems. Its pretty easy to notice when a minor change in game design means a lot of work. And then its just a few google searches away to find the best practices designed to solve the exact problem you are facing.

That would be me. Almost every time I've used a singleton, I get to a point where it no longer makes sense to use one, and then I need to switch to something else. Based on this general experience I don't start down the path of using a singleton.

And if I do use one, I tend to code it very defensively. Its probably not going to do the job in the long term, so I might as well be ready to remove it from the start.

 

We use singletons for things like

MaterialManager.Instance.GetMaterial(transform);

However I wouldn't have done it like this in a none game, then I would have used a DI container and if needed configured the MaterialManagers lifetime to singleton. Anyway, now I'm babbling.

To communicate between components we use a EventAggregator, which is a much more decoupled way than singletons

 

Singletons are great! But only as long as they are used correctly. From what I can tell, most people use them when they need easy access to a class from anywhere in their code. Just make it a singleton, and you can call MyManager.Instance from anywhere to get a reference. This is not a good reason to use a singleton, and if this is your only purpose you should use a different approach.

However if what you want is to make sure there is only one instance of a class at any time, then the singleton is the correct solution. For example if you have some limited system resource, it makes sense to have just one instance of a class for interacting with it. The most common, but perhaps not the best example, is the log writer. You only have one log file, so it makes sense that all interaction with the log goes through a singleton class.

If you only want easy access to an object from anywhere in your code, you are better off using some kind of inversion of control. This is your Service Locator or Dependency Injection. You don't actually need to use any of these to have inversion of control, simply passing the object as a parameter could also be considered inversion of control.

In my opinion, this is not a solved problem in object oriented programming. Dependency Injection is the most recent attempt at solving this, but for me I don't like how you need to set up all the relations in a single place, and then have to rely on black magic for the references to be resolved in all your other classes.

My favorite solution is to use "manual" inversion of control, and just pass the objects along in the constructors. Yes it might make the parameter list a bit longer, but I don't really see this as a big deal. The problem with doing this in Unity though is that classes derived from MonoBehaviour shouldn't have constructors, and it really doesn't fit with Unitys component based paradigm either.

I've had my bit of back-and-forth on this, I've tried singletons, dependency injectors, service locators and just setting references in the inspector. I'm currently using the service locator pattern in Unity, and it works reasonably well. Managers just register/unregister with the locator in OnEnable/OnDisable, and I can have single or multiple instances registered.

It works, it lends itself well to testing as long as I use interfaces, and the flow is relatively easy to follow. It's no silver bullet though, so if anyone comes up with a better solution I'm all ears.

 

Been there, done that. At some point I even accidentally tried making games!

 

I agree with most of what you wrote, but just wanted to share my opinion about the part I quoted.

I assume it to be a good thing that DI container acts like a 'black magic' (or 'black box', if we want to use a bit more technical term) to the classes it deals with. Dependency injection pattern was devised to move the responsibility of resolving or managing lifecycle of services and resolving them from the business layer to an outside platform, so it's better if all the details about resolving dependencies could be abstracted away from the business (game) components themselves.

And the fact that you can manage declarations of services and their dependencies in a centralized manner (it does not necessarily have to be in a single class or a configuration file, though) can be seen as a feature, rather than a limitation, as it can serve as documentation of some sort, which shows what kinds of services are there in the context and how their lifecycle and dependencies are managed.

By the way, you can actually use constructor injection with DI plugins like Zenject in Unity. I'm currently experimenting such an approach in my project, and I think at least it's possible to construct most part of a game with POCOs.

Probably there might be some headache later when I'll have to implement save game feature, but I believe it could be circumvented by introducing a custom state saving structure. And one can always take a more conservative approach and only use POCOs for non-game object type services in place of singletons, and they can freely declare dependencies in their constructors with a help from the DI container.

Anyway, I agree that declaring all the required dependencies of a class in its constructor to be a best practice, and it's supported (and even recommended) by most of the DI container implementations. As DI container is a 'black box' for resolving dependencies, it should not change the way we design our business classes, which includes such best practices like declaring dependencies in a constructor.

 

It was more tongue-in-cheek reference to using the dark arts, rather than the opaqueness.

I'm not going to stubbornly say never use DI, if it works for you or anyone else, then great. I just personally don't like the way it makes me structure the code, especially in Unity. I certainly see the problem it is trying to solve, and I agree that it is a solution, but I wonder if one couldn't come up with a better solution.

 

Just don't forget to share it on the forum if you find it I'm always interested in finding new ways to make my code better.

 

Another thing to keep in mind that I forgot about earlier is that if you structure your projects to use some kind of messaging system(s), then you can avoid the need for getting most of these object references in the first place.

 

If you're the solo programmer, anything is fine. But in general I have at least 5 in a project. Maybe more if more managers or such are needed for something. Singleton is a great pattern for Unity work.

 

Why do you need singletons surely every object in Unity has a unique id/reference/name/tag/layer.

Or you can just set up a reference to it and link it in the editor?

Or couldn't you group related elements under a root/'singleton' transform?

Or does unity have an event system like the sound system with sounds and listeners, where you could specify that certain objects are to be managed/monitored by another?

This could work great for pooling objects as well as they would respond when objects die.

 

Singletons are often the simplest solution to the following problem in Unity.

• State needs to be globally accessible
• Only one version of the state should exist
• The state needs access to Unity functions associated with a GameObject

There are of course other ways to do this. But none are quite as simple as rolling up a singleton.

 

So it's a posh OOP global variable then!

Aren't global variables bad, as they encourage tight coupling of code?

 

Found this interesting article on dependency injection, should Unity provide this as Unity is the Builder?



So would Unity need to add a MonoBuilder class that can do the dependency injections for MonoService classes?

Apparently a lot of people don't like the Singleton pattern "Patterns I hate #1 Singleton" (http://puredanger.github.io/tech.puredanger.com/2007/07/03/pattern-hate-singleton/)

Does the need for a Singleton show a flaw in Unity's "Architecture"?

 

Apparently a lot of people don't finish games and would rather spend time with architecture. Did you know Unity uses the singleton pattern with it's own API frequently?

It works fine.

 

Actually, Unity itself already does act like a dependency injection container of some sort. Think how you can declare properties of a MonoBehaviour class using interfaces (let's forget about serialization for a while), and assign game objects in Inspector to them with components which contain actual implementations. That is almost exactly how dependencies are injected in the picture.

There are some limitations (i.e. not supporting POCOs, limited lifecycle supports, and etc) and questionable design decisions, of course. But overall, it's already one of the main features of Unity platform and considering there are number of DI container implementations that work on the platform, it's hardly justifiable to say that Unity forces developers to use singletons because it doesn't support DI.

 

This is actually why I ditched the first DI container I used for Unity. After going through the code, I realized all it was doing was getcomponentinparent then like a type dictionary lookup (with some extra bells and whistles).

After seeing the implementation I couldn't justify it anymore. I wrote a couple attributes that do population for fancy shorthand.

[FromParent] private MyMono MyMono;

Later I moved onto just writing the code out.

When I finally switched to a multi scene approach, I ended up building out a type registry again for accessing stuff cross scene which made more sense at the time since all the scene loads need strict management (so that I don't access stuff before the scene is loaded for example).

 

@frosted Yeah, I can see how writing a micro simple attribute or even just relying on Unity to handle dependencies can be sufficient, if you don't need other features that DI containers usually provide.

Personally, I've been using DI containers too long that I almost feel like I can't write anything without them. I felt that way when I first moved from Java to Scala, and found out that DI containers are not that popular among Scala programmers so I tried to do without them for a while before I gave up.

When I started learning C# and Unity early this year, one of the first things I did was finding a proper DI container plugin to use and ended up with Zenject. I like how versatile it is in terms of binding and construction options it provides, but found it to be rather inconsistent in handling lifecycle of managed components.

Probably it's kind of a thing that depends much on personal preferences. So, even though I'd recommend trying a DI container for anyone who's trying to replace singletons in their Unity projects, I'd certainly understand that if one can easily do without them using different approaches.

 

In really practical terms, my main problem with DI in Unity (or even attribute based approaches or whatever) tend to revolve around how I use Unity, which is a mixture between coding and working in editor.

In general, while working in the editor I want the dependencies to be as transparent as possible, so I can make sure I have whats needed (and to help remind me how something works if I haven't looked at the code in a while). Ideally I don't want to look at the code while I'm working in the editor and vice versa. I want to stay in one mode as long as possible to complete the task.

I've found that personally, having as much transparency in the editor as possible ends up being easier to work with (it causes the fewest mistakes). The idea being that I don't need to switch into the IDE from editor very often and that my view from the editor gives enough hints as to what a thing does and what it needs.

I agree though - this kind of thing comes down to preference - and if I wasn't trying to solo the project and didn't need to constantly toggle between editor and code - I could see the flexibility being more valuable than transparency.

 

Games often are tightly coupled systems by nature. So jumping through hoops to pretend they aren't can lead to all sorts of silliness.

 

This. A thousand times this. A loooooot of people don't understand this. (Not just in game code, in general - some functionality is inherently coupled - decoupling code that cannot realistically be decoupled is the cause of some of the worst design ever).

 

Need to read up on DI in Unity, can we do advanced lifetime/scope stuff like this?

https://andersmalmgren.com/2015/06/23/abstract-di-container-scopes/

 

We could, but I'm far too busy having fun finishing something

 

I just reference it as any other component. Same as with a singleton, you have to make sure there is only one in the scene.

Code (csharp):

1. public class Whatever : MonoBehaviour {
2.  
3.     private GameManager gm;
4.  
5.     void Awake()
6.     {
7.         gm = GameObject.FindObjectOfType<GameManager>();
8.     }
9.  
10. }

 

So you you created a situation where you are likely duplicating that logic all over the place.

Instead of that create say a GameBehavior class deriving from MonoBehavior. In that put getter properties for your managers. Now your behaviors can access your managers as a protected property, and you aren't duplicating logic. It's easy to scope this to whatever you want (global/scene).

Code (csharp):

1.  
2. protected AgentManager AgentManager
3.         {
4.             get
5.             {
6.                 if (agentManager == null)
7.                 {
8.                     agentManager = Object.FindObjectOfType<AgentManager>();
9.                 }
10.                 return agentManager;
11.             }
12.         }
13.  

 

You can also use the resource folder if you have seriliazed data that goes with it

Code (CSharp):

1.         public static MaterialManager Instance
2.         {
3.             get
4.             {
5.                 if (!instance)
6.                     instance = Instantiate(Resources.Load<MaterialManager>("MaterialManager"));
7.  
8.                 return instance;
9.             }
10.         }
11.  

 

Why?

I've used this approach in several successful mobile games. What's wrong with Sfx.Instance.Play or VideoAds.Instance.Show or FacebookAssistant.Instance.Share or IAPs.Instance.Purchase or Progress.Instance.SetPuzzleCompleted?

 

You get a tight coupling which is bad

 

If you are sure that you won't need to have multiple implementations of those services and don't want to make your project extendible, then probably it's not so bad.

I can see how some mobile game projects won't need to be very flexible in their structure. But it's not much of a hassle to do away with singletons either.

Actually, it takes less typings to write a single service locator singleton, for instance, than to make every services as singletons, not to mention of making it more flexible by reducing unnecessary couplings.

 

You say it's bad but I don't recall having any problems getting several projects finished and onto player's devices. Plus no problems maintaining these projects for updates.

 

Well there's effectively no typing as I have a generic base class in script templates so it's as easy as asking Unity to create a new script.

 

Service locator is offcourse better than singletons, but its also a anti pattern just less of a anti pattern.
DI with constructor injection is the purists choice, offcourse in gaming dev there are performance etc to think about. But in the business world I always use DI with contrutor injection for low coupling to the DI.

I love writing cool DI abstractions, like this one, https://andersmalmgren.com/2015/08/27/parallel-executed-tasks-with-isolated-scopes/

 

Well, a boiler plate code is a boiler plate code, whether it's automatically generated or not.

But I'd like to ask, if you are absolutely certain you won't ever need any flexibility whatsoever, and also don't mind violating a few best practices as long as it works, why do you bother with singletons at all?

If I was in that position, I would just declare every methods and properties as static, then I won't have to type ".Instance" everytime I need to call those services.

I know, and I'm all for the 'purist' approach myself

 

Nobody cares if you can maintain your own code