Is it safe to use constructor for classes inheriting MonoBehaviour?
I’m aware that non of engine initialization for the object is done at this point. I only need a reference to the object that is consistent and does not change. Basically I’m just trying to get a reference to object created an assign it to some static readonly variable. As far as I have tested this works no problem but I’m kind of new to unity so I want to confirm.
Also I’m aware of other possible solutions (Lazy loading/assignment inside awake function/execution order change/ etc.) but I want know if constructor is usable or not. If not please give some example elaborating on the scenario it does not work.
Basically Im trying to do something like this code(The class is supposed to be singleton)
Well, yes it could be but there is a problem. the _Instance reference variable would be null if for some reason it is accessed after object construction but before awake is called. Obviously I can rearrange execution order for that to ensure that it is always initialized before other objects but there is a problem there as well. this is supposed to be a generic singleton abstract class. If I resort to using execution order rearrangement I should do this manually for all the classes that inherit this. Though execution order change does guarantee that the objects are initialized in that order too and not just the existence but I don’t really need that guarantee.
Another option would be lazy loading the reference using a property (or getter) but then ensuring that only one instance of the object exists becomes complicated as I need to do the assignment in both the getter and awake function and then inside the awake check for singleton constraint and handle any case where additional objects are created(I’m planning to handle multiple object creation cases inside the constructor as well). Also if getter is accessed by two different threads before awake is called in some rare race conditions I might end up destroying the object that was assigned to _instance while leaving the object that was not assigned and to manage that I need to do a == null check inside the getter/property instead of just if (_Instance) which means additional overhead.
So, basically to avoid all these complicated stuff I would like to use the constructor if possible…
Well as far as I’m aware, the behaviour of monobehaviour constructors is undocumented and undefined. To that end I personally would not rely on it, as it could potentially change at any point. And you won’t be able to complain about the change as it is, as I noted, undocumented and undefined.
From my understanding it happens during serialisation, which runs more often than you think, and is also a threaded process.
Then just don’t do this. Awake is for self initialisation. Initialisation that depends on other objects being ready happens in Start/OnEnable. It’s a simple rule to follow that avoids these problems.
No singleton should be this complicated. This feels like either massive over-engineering, or a defective singleton pattern.
Personally my singletons just lazy load, and only lazy load. They also do not get included in any scenes. They lazy load, usually instancing themselves, and then hitting themselves with DontDestroyOnLoad.
And that’s only when I’m using a singleton monobehaviour. Most of the time a static class is all I need. Or I use a singleton pattern scriptable object, so it doesn’t depend on a scene at all.
Constructors not for you to use, it is for the Unity Engine to initialize your objects. They are called every time Unity is deserialize or create your Component for any reason.
This is ONE time run in the editor. And here is the code:
using UnityEngine;
public class Test : MonoBehaviour
{
private static int _counter;
public Test()
{
_counter++;
Debug.Log($"Constructor for Test number {_counter}");
}
}
Out of the three, two calls go before play, one AFTER play (when the editor scene reinitializes).
Also called when you create a game object with your component on it, but without domain reload, so whatever was your state last time, the constructor will be called with it. Without entering play mode(!).
This is dangerous and should not be used at all. Stick to the standard and recommended way to handling components.
All of these on top of any possible “Domain reload off”-setting. So that’s further complicate this thing.
It’s theoretically possibly to use a constructor for this. But because of the reason that @Lurking-Ninja pointed out, it’s not a great option if the singleton object goes through the deserialization process. Three different instances get loaded as part of the deserialization process, and dealing with them would get hacky:
using UnityEngine;
using System.Collections.Generic;
public abstract class Singleton<TDerived> : MonoBehaviour where TDerived : Singleton<TDerived>
{
static readonly List<TDerived> instances = new(3); // <- might need to use a thread safe collection here instead
public static TDerived GetInstance()
{
for(int i = instances.Count - 1; i >= 0; i--)
{
var instance = instances[i];
// Remove references to prefab asset and temporary
// deserialization-related object that no longer exist.
if(IsNullOrPrefab(instance))
{
instances.RemoveAt(i);
}
}
return instances.Count == 1 ? instances[0] : null;
}
static bool IsNullOrPrefab(TDerived instance) => instance == null || !instance.gameObject.scene.IsValid();
public Singleton() => instances.Add(this);
~Singleton() => instances.Remove(this);
}
If the singleton was created at runtime via new GameObject.AddComponent<TDerived>(), then only one instance actually gets created, and then this would be a more viable pattern.
You could also use ISerializationCallbackReceiver.OnAfterDeserialize instead of the constructor, but that would still also get called more than once, so it wouldn’t make much of a difference.
You might also need to make your code thread safe, if you use a constructor or OnAfterDeserialize to assign anything to static variables, because the deserialization process takes place on a background thread
Personally I do use constructors in components from time to time, but mostly only to initialize readonly member variables.
A simpler solution would be to create an AssetPostprocessor that detects when a MonoScript for a singleton-derived type gets imported and sets its script execution order setting to a very low value automatically.
This is the go-to way to implement the singleton pattern in the Unity world. It’s not that complicated, and you only need to write the code once.
You can’t use things like FindObjectOfType or Destroy outside the main thread anyways, so if you use lazy loading, you can’t ever call the singleton accessor from outside the main thread. So you don’t need to worry about race conditions in that case.
Technically speaking, that is not an implementation of the singleton pattern, but just a static property with lazy loading.
It’s missing the key functionality of preventing extraneous instances from being created by other classes:
With a plain old C# class implementing the singleton pattern is super easy - just make the constructor private and initialize a public static property with an instance:
public class Singleton
{
public static Singleton Instance { get; } = new();
private Singleton() { }
}
But with a component a little bit more code is needed to get the same functionality. For example:
