koobas.hobune.stream
Am I "misusing" the concept of statics with this implementation?
In each of the scenes of my game there are a number of "Module" objects. Certain operations require a list of all Modules in the current scene. I dislike using some sort of "ModuleHolder" class to hold a reference to all Modules because this needlessly splits Module-related code across two separate classes. My solution has been to find all objects of type Module when the scene loads and store this in a static array in the Module class itself.
This works swimmingly with one caveat. As different scenes have different modules (and even reloading the same scene creates different instances of the same Modules) I need to reset the array holding all Modules on any scene change. This leaves me with a nagging feeling that I am using statics "incorrectly" in some way.
The fact that my current implementation just works may be paramount, but I was wondering if there was perhaps an alternative way to do this that I might be missing. Any thoughts (or reassurances that I am not, in fact, abusing the static property)?
$$anonymous$$y thought is that you should stop worrying about "needlessly splitting related code across two separate classes". Having a type and then a manager of some kind that manages objects of that type is a common and useful idiom. It's not "needless", it's powerful and flexible.
100% agree with @Bonfire-Boy here.
When i read the OP say
I dislike using some sort of "$$anonymous$$oduleHolder" class to hold a reference to all $$anonymous$$odules because this needlessly splits $$anonymous$$odule-related code across two separate classes.
I facepalmed hard.
I prefer statics over singletons, because a singleton has other things going on off the bat, and there is an incredibly simple method of making your statics work how you want for swapping scene data. This is what I personally do.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using UnityEngine;
namespace myExample
{
public static class ExampleManager
{
public static exampleScripts[] MyScripts
{
get
{
if (myScripts== null)
{
MyScripts = GameObject.FindObjectsOfType<exampleScripts>();
}
return myScripts;
}
private set
{
myScripts = value;
}
}
private static exampleScripts[] myScripts;
}
}
When you switch scenes, any scripts in that scene are of course no longer being referenced, so you make your static file never return null by auto-filling the reference with whatever you intended.
This is precisely what I'm doing, however I am not using a handler but rather storing the static array of $$anonymous$$yScripts in exampleScript itself (using your notation).
@SlimeEnthusiast You're right about them sharing the single static array. But it is inefficient because every instance will reinitialise the array using Find. Ins$$anonymous$$d, they could each just add themselves to the array (in this case one would probably facilitate that by using a List ins$$anonymous$$d of an array). This would improve efficiency since you wouldn't need to use Find at all.
You could also use OnDestroy to remove them from the list as and when they are destroyed individually, which could sort out your whole scene-change issue.
In other words something based on this...
private static List <ExampleScript> allExampleScripts = null;
void Awake()
{
if(allExampleScripts == null)
{
allExampleScripts = new List< ExampleScript>();
}
allExampleScripts.Add(this);
}
void OnDestroy()
{
allExampleScripts.Remove(this);
}
With regard to the singleton manager approach, I use managers of the sort I described all the time, and have done for over 30 years with no serious problems. Like I said, there are gotchas, but there always are when you use static data. With a singleton manager class, once you've got a pattern for the singleton itself that works (which isn't hard in Unity I$$anonymous$$O) you can forget all that. The only static field you have is the singleton instance, the functionality of which is totally hidden in the singleton class.
