Hello guys!
I just wondering how you implement singleton for MonoBehavior components
Here is how I do it. I use this two methods depends of situation.
The first:
public class MyController : MonoBehaviour {
private static MyController _insatnce;
//--------------------------------------
// INITIALIZE
//--------------------------------------
void Awake() {
_insatnce = this;
}
//--------------------------------------
// GET / SET
//--------------------------------------
public static MyController insatnce {
get {
return _insatnce;
}
}
}
And the second one:
public class MyController : MonoBehaviour {
private static MyController _insatnce;
//--------------------------------------
// GET / SET
//--------------------------------------
public static MyController insatnce {
get {
if(_insatnce == null) {
_insatnce = new GameObject("MyController").AddComponent<MyController>();
}
return _insatnce;
}
}
}
And I always wanted to find solution, how to build base Siglethon class.
I mean if I will deliver any component from this base Siglethon class the component will become Siglethon.
Probably somebody know elegant solution how to do this.
using UnityEngine;
public abstract class SingletoneBase<T> : MonoBehaviour
where T : class
{
/// <summary>
/// SingletoneBase instance back field
/// </summary>
private static T instance = null;
/// <summary>
/// SingletoneBase instance
/// </summary>
public static T Instance
{
get
{
if (instance == null)
{
instance = GameObject.FindObjectOfType(typeof(T)) as T;
if (instance == null)
Debug.LogError("SingletoneBase<T>: Could not found GameObject of type " + typeof(T).Name);
}
return instance;
}
}
}
MyController singletone
public class MyController : SingletoneBase<MyController >
{
///TODO:
}
Patico’s solution will work. There are several different ways to truly implement the singleton pattern. One thing you have to be careful with is concurrency. Patico’s implementation isn’t really thread safe in that if you have MonoBehaviors being created in two separate threads, both could see the _instance variable as null and both could initialize it.
In your example though, you’re not really going to create a singleton. Every time an instance of the MonoBehavior is created it is going to reassign it to the _instance static variable.
And actually, in either case your behavior isn’t actually a singleton. What’s happening is you’re taking the first instantiation of your MonoBehavior and you’re storing it in the _instance variable. Every other time, the behavior is still getting instantiated, so you’re still getting a new instance every time, but if you’re using the _instance variable, you’re going to be working on the same actual instance of the behavior.
MonoBehaviors aren’t really designed to be singletons either… so let’s say you have stuff that happens in Update and FixedUpdate. Update and FixedUpdate will still be called for every gameobject you have this behavior attached to. Not only that, you will need to do something like this:
void Update()
{
_instance.Update();
}
Of course you could use a Factory to implement it… something like this:
public static class BehaviorFactory
{
private static Dictionary<type, MonoBehavior> Behaviors = new List<type>();
public static T GetBehavior<T>() where T : MonoBehavior, new()
{
T result = null;
if(Behaviors.ContainsKey(typeof(T))
{
return Behaviors[typeof(T)] as T;
}
else
{
var result = new T();
Behaviors.Add(typeof(T), result);
return result;
}
}
}
Then you’d have to add your behaviors through code using your factory to assign the instance. You’d still have the issue of the lifecycle methods being fired more than once. You’d also have the issue of your behavior getting destroyed if your gameObject gets destroyed.
My example are the simplest implementation of this pattern, and sure it not 100% safe. But this is enough in 90% cases, at least for me
The first example can be used only for components with are on stage after initialization (you do not create them in runtime)
And the second will work fine if you call it only thru instance getter.
Patico suggested really good implementation. Yes it’s not thread safe. Let’s remember that Unity API is also not thread safe. Point is that if soumebody will need thread safe Patico’s solution can be extended by adding double lock. But I guess that there is not mutch people who use Threads instead coroutines.
If you really need to channel the lifecycle methods through a singleton (have exactly one instance executing Start, Update, Awake, etc…) then use “delegate” and “singleton” patterns together.
Create a templated Monobehaviour that owns a singleton that is not a monobehaviour
that singleton should mimic monobehaviour interface (but NOT be a monobehaviour because u don’t want to instantiate monobehaviours yourself). Create your own interface for that possibly.
have your monobehaviour delegate all lifecycle calls to a singleton. It can even pass additional parameters if your singleton needs to know for example the transform of the caller.
Yes, it is simple non tread-safe implementation. If you want a tread-safe - all you need is to add a double checking lock pattern wiki.
But, I’ve not used locking in Unity yet, if this is well supported by engine, then next code should works well and tread-safe:
using UnityEngine;
public abstract class SingletoneBase<T> : BaseMonoBehaviour
where T : class
{
/// <summary>
/// SingletoneBase instance back field
/// </summary>
private static T instance = null;
private static readonly Object syncRoot = new Object();
/// <summary>
/// SingletoneBase instance
/// </summary>
public static T Instance
{
get
{
if (instance == null)
{
lock(syncRoot)
{
if (instance == null)
{
instance = GameObject.FindObjectOfType(typeof(T)) as T;
if (instance == null)
Debug.LogError("SingletoneBase<T>: Could not found GameObject of type " + typeof(T).Name);
}
}
}
return instance;
}
}
}
I know this thread is super old, but I’ve revisited it many times over the years because I’ve never been quite satisfied. I want to set up a singleton with as little code as possible, and I also want that setup to not interfere with existing inheritance for the class in question. Anyone who has set up a few singletons with generics and inheritance knows that it’s a pain in the butt to try to inherit anything into your singleton while its in this configuration. So I thought I’d try setting up a singleton via property declaration instead. It occurred to me that If I keep the property name short, then it’s only two extra keystrokes to ref the instance, which feels like a wonderful trade-off for me when it gets the singleton setup out of the inheritance tree. Here’s a first pass:
using System;
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
/// <summary>
/// A singleton designed to set up via property declaration rather than class declaration
/// so as to avoid interference with any existing inheritance structure
///
/// /// Setup:
/// public class YOURCLASS : MonoBehaviour
/// {
/// public static Singleton<YOURCLASS> _ = new Singleton<YOURCLASS>();
/// }
///
/// /// Usage:
/// YOURCLASS._.Instance.DoStuff();
///
/// </summary>
/// <typeparam name="T">the type you want to declare as a singleton</typeparam>
public class Singleton<T> where T : MonoBehaviour
{
public T Instance
{
get
{
if (m_Instance == null)
m_Instance = (T)GameObject.FindObjectOfType(typeof(T));
return m_Instance;
}
}
private static T m_Instance;
}
That’s not really a Singleton though because you can have multiple instances of YOURCLASS attached to many GameObjects. That’s just a MonoBehaviour with a static reference to some other MonoBehaviour (which may or may not be itself)
I’m aware, but I personally prefer them not to be real singletons. I do not want accidentally duped singletons deleted automatically, so I usually delete that part from singleton implementations. Instead, I prefer error handling on duplication, which is still technically not a singleton because the error doesn’t stop a multiple-instance situation… it just flags your attention to it. But that’s what I prefer. I just haven’t put that in here yet bc this is a first pass. The point is more that you can implement a singleton any way you want via class OR via property, and it all works the same way. Only difference is a couple extra keystrokes to reference the instance. RE: That’s just a MonoBehaviour with a static reference to some other MonoBehaviour… no. It’s a MonoBehaviour with a static reference to itself. A singleton of sorts. Just like feeding a child class type ref into its parent class as a generic is a monobehaviour inheriting a static reference to itself. The only difference is syntax.
Yup, exactly. This was the first thing I wrote and realized it’s the core of what I wanted, but then realized I still want to template-ize other common aspects of a singleton like error handling, locking, and duplication deletion. Mine started as the same as what you’ve got here, but then I abstracted the property to open up the ability to add all that extra stuff.
I’m having a hard time imagining what kind of locking and error handling you would need here. And I don’t really know what duplication deletion means. I certainly don’t see any of that in your code.
Were you going to add it later? Are you leaving it as an exercise to the reader? If the latter, I’m afraid I would need more context to understand how to do that.
var a = new GameObject();
var b = new GameObject();
var first = a.AddComponent<YourClass>();
var second = b.AddComponent<YourClass>();
second’s static reference is actually to first, not itself.
I also think it’s generally better for the static reference to instantiate itself fully the first time it’s called. Your implementation relies on someone putting the component in a scene somewhere ahead of time so there’s a chance Instance will be null.
Again, I’m aware of that. What I posted was a first pass. The fact that I didn’t add duplication deletion yet does not mean it’s impossible to do so. Like I said, you can easily add it the same way as in the generic derived class implementation. There is no difference between declaring the singleton as a property vs. a derived class, except syntax. I don’t personally care about duplication deletion, but if you really need me to prove they’re equivalent, I can code you an example.
I didn’t intend to add any more to my post. It was just an idea that I thought would be interesting for people who like to build their own singletons. Locking and duplication deletion are covered in previous posts in this thread. The go-to singleton implementation in the Unify wiki does both. You can copy the contents of one of those solutions and paste it into the body of the code I posted. The only thing unique about my way is that it lets you declare your singletons as properties instead of declaring them as generic derived classes. Everything else can be the same.
It’s not common to put error handling in a singleton bc widely shared forum code with Debug.Log statements can be annoying, but all it means is when a duplicate is found, throw an error to the console instead of deleting the duplicate.
My mistake, the wiki only does locking, which is not useful in Unity anyway for a MonoBehaviour since it will always init on the main thread unless you job it, and if you have to job singletons, you’re probably making too many of them.
RE: “no chance the instance will be null,” I despise null-check instantiation in singletons. If someone wrote a race condition, I want the console to throw an error at them immediately so they know to fix it. Singletons instantiating themselves on the spot is an instant havoc recipe in my book, but to each their own. Like with all the other things, you’re welcome to add null-check instantiation, whether via generic derived class singletons or via property singletons.
There’s a lot of back-and-forth about what constitutes a singleton in this thread. In the spirit of hoping to avoid reiterating that I don’t think any of us need most of the features that are popular in Unity singletons, the following are 100% completely IMO what a singleton needs and does not need, and why this works perfectly for me:
Do Need:
Fast declaration syntax for any number of classes that may or may not have their own inheritance pattern already
Fast accessor syntax
Duplicate error handling just in case (very rarely needed)
Don’t Need:
Locking
Duplication Deletion
Null-check instantiation
Multi-instance discovery handling of any kind, really
In general, my singletons are singletons because I decided there’s only one, not because the code guarantees there’s only one, and that’s usually plenty good enough for me, and for the teams I’ve worked with. The name Singleton implies it. Has anyone here run into a situation where you needed the code to guarantee it? If the team sees the name singleton, they know it’s a thing not to be duplicated. If you’re afraid someone will goof this, throw an error on duplicate discovery. If a singleton that doesn’t have multi-instance handling doesn’t count as a singleton according to the community at large, we can agree to disagree.
My singletons are either pre-installed in an init scene, or a core Init script instantiates them prior to any scene load. They should not be created using AddComponent, Instantiate on an intra-scene prefab, etc. Singletons are top-level classes (God-mode classes) to be used very sparingly. Scenes, objects, and scene-level behaviours are not allowed to create singletons in my code. Singletons have authority over scenes and intra-scene prefabs, not the other way around. When I use them with teams, we agree upon singleton usage guidelines. They’re super dangerous if different team members use them differently, but if everyone’s on the same page, duplicates usually aren’t a thing.
Telling your fellow team members not to dupe singletons is sort of like telling them not to call a private method from outside its class. 1) Obvious. 2) A thing that obvious should turn your console red if you overlook it. But the popular way with Unity singletons is to paper over that mistake and then build extra handlers to clean up the aftermath too. Time spent handling multiple instances is not just wasted… it causes more problems than it solves. For example, ScriptA calls a singleton accessor. Singleton constructor shows the singleton not found… a) give ScriptA’s author a null ref? Or B) create a new singleton on the spot and pretend ScriptA’s author messed up nothing… Problem is, the singleton you wanted is about to be instantiated next frame. ScriptA’s author could yield for it, but they didn’t even get an indication that they just created a race condition. If your singleton implementation creates a copy to paper over the race condition, next frame you have two singletons, and now it’s a good thing you built that duplicate handling. Rather than using singletons in an error-prone way and doing extensive work to paper over the mistakes the team doesn’t know they’re making, just let them have the errors that reveal their mistakes in the first place, and they’ll quickly learn how to use singletons correctly.
