How share class between scenes WITHOUT singleton?

Hi all,
I find singletons most ugly thing I even seen in programming. I am not going to use them ever, so question is simple - if I have a class with objects (not only basic types) and even arrays of objects, is there any way to share it between scenes WITHOUT using singletons?

 

This could help you: https://gamedev.stackexchange.com/q...-the-proper-way-to-handle-data-between-scenes

 

That's a nice summary page but amazingly they do not mention ScriptableObjects shared between scenes.

I keep hearing people say this sort of thing and yet every time I corner someone on it, it turns out they are just repeating what they heard in programming class in high school and they actually don't have anything like an actual reason.

Do you have a reason you feel singletons are ugly?

 

glgamesforfun
Thanks, I will look at it.

There are too many reasons:
1. Singletons in practice are same as globals.
2. Testing singltoned code is a hell.
3. Singletons can become big problem for garbage collector and I find it super ugly to destroy and recreate same object, only because you can not find better solution.
4. Singletons suck at multithreading.
5. Singleton is controlling itself - which is absurd for OOP.
6. Singleton uses static, which also bad idea if you need to CHANGE static members, not just use, because it is another name for GLOBAL.
and many many more.

 

So is the screen, the input device, the asset resource database, the network adapter, etc.

For that matter, so is the player and the game... what fraction of game installations out there are actually running more than one game instance at once?

Globals are AWESOME. One and done.

Not in my experience. It's just code. Put a breakpoint in it or instrument it and test your code, fix your bugs.

I don't even know what to tell you there. Clearing everything out to a blank slate and recreating everything new and afresh is one of the best ways to eliminate bugs and initialization logic flaws.

News flash: Unity scripting is 100% single-threaded... you cannot even ATTEMPT multi-threading and manipulate the Unity API. It's completely and totally illegal, at least outside of DOTS/ECS.

Maybe you'd be happier over in DOTS/ECS land?

 

Globals are another name of catastrophe - it is worst thing in programming. The only equally super terrible thing I can name is Goto command. Sorry, but I can not argue with a person, who finds globals awesome.

 

Yes, I suppose you cannot. That's how awesome globals are!

Good luck in your travels.

 

Yes, that's why one WILL BE KICKED from most software companies, if he dares use globals. They even have mottos written on walls: "never ever dare use globals!"
Good luck.

 

This. The Singleton pattern is in well known books like the "Gang of Four" design patterns book for a reason. One thing to be wary of with enterprise practices is that they're not always set for sensible reasons. There are entirely too many in that field that follow practices because that's how they've always done it and are adverse to change.

https://en.wikipedia.org/wiki/Design_Patterns

Worse yet they often pass their practices onto people new to the field who will then carry on the torch of choosing to use it because that's how everyone else did it even if it doesn't make sense once you step back and take a good long look at it. If you have to keep it in places everyone can see it's probably not as sensible as you thought it was.

 

The thumbnail makes this guy look like Dennis Reynolds.

EDIT: To add something relevant to the discussion, Unity is already filled to the brim with globals and singletons. The SceneManager is static, and you can access everything through static methods in GameObject among other things.

 

One alternative is to use a (static) service locator. It's still global, but solves some of the "issues" of singletones (for example unit test), so it's more accepted by the community who otherwise "hate" singletones.

For testing (I assume you mean unit test) you can create a interface for the "service" instead of using the implementation and then use the ServiceLocator to get the interface (then you can just add a mock during unit tests)

I usually don't need any singletones for my games, but in some rare cases global easy access is nice and I break the "rules" because most of the Unity things are static anyways, in that cases I just use my static generic ServiceLocator (less than 10 lines of code).

Btw I work in a big company which developed software for over 25+ years (desktop application, not a game) the code base is massive but also uses a static ServiceLocator (more fancy than my private game implementation, but still static), so a "evil global" and no one was fired yet and most of the code (at least new written code) is unit tested, which works perfectly fine with the ServiceLocator.

 

People hate on singletons because they are globals, but almost all alternatives are ultimately still globals in disguise. Pretty much anything your class accesses which was not passed to it from some external code is technically a global.