@jeango To be frank that’s just the Singleton Pattern. It doesn’t do anything differently that singletons do, and is also vulnerable to the same issues that plague Singletons.
By their very nature, Singletons invite tight coupling due to implementing to a concrete class. By definition they use statics and you can’t abstract away statics easily (though its possible with some clever use of Extension Methods). Singletons also cause a slew of headaches with Unit Testing, multi-threading, and really its just a fancy word for storing a global state, all of which are (or can be) bad.
Thats not to say that you shouldn’t ever use singletons, on smaller projects they’ll work just fine. but singletons are like minefields, you need tread around them carefully, which is easy on small projects. When you get to huge projects that involves a larger team Singletons are just not the answer (like pushing a parade through a minefield instead of a party of 5, things are far more likely to blow up).
At that point Dependency Injection (DI) is the way to go. Then you don’t make classes singletons, you make them single instances that are manually passed to the classes that need them (preferably via a multitude of interfaces). Since these single instance classes are no longer Singletons they don’t need a static reference for themselves anymore and thus no longer manage their lifetime anymore. instead you would have a factory (enter Factory Design Pattern) handle that. The factories don’t need any static reference to the “mock singletons”,but they can just hold an internal reference and if the instance is null they make one, otherwise they pass back the pre-exisiting instance. The factory themselves can also be abstracted behind an interface.
By using DI it makes every class’s job easier as they have no idea which concrete class the data they want is from (making them Decoupled) plus since that data is “pushed” to the classes that need them, (those classes no longer try to “pull” them from some global state), it becomes significantly easier to mock that data (great for unit testing). the classes using the data no longer need to know that the data is from some singleton nor need to understand the lifetime state of said classes. They can just focus on their specific use-cases
But the thing to understand is that the MyComponent class is only there as a kind of placeholder to show you the usage of the other stuff.
Just making it a subclass of Component would fix it the compiler error (note: don’t do this, continue reading!).
[System.Serializable]
public class MyComponent : UnityEngine.Component
{
public string anotherGlobalVar = "yeah";
}
In practice though, the idea is that MyComponent is a MonoBehaviour. If it is , then it will also compile because MonoBehaviour derives from Component.
So you don’t actually want to use the MyComponent bit of that code at all. Just use one of your own MonoBehaviours in the place where they use the MyComponent class.
The page really doesn’t explain it well.
Personal opinion: for me this is all a bit over-the-top. In Unity I use a lot of singleton MonoBehaviours, of various types (eg with scene or application lifetimes, created in the inspector or at runtime, whether from prefabs or not, and so on). They can simplify ones code massively, the benefits of which can outweigh other considerations. Some people go on about them being awful code design but really, you just have to be careful. I’ve been using singletons for over 30 years and literally never had a major issue caused by it.
[Edit: this opinion-piece was based on my own misunderstanding of the nature of the ToolBox and its intention! Hopefully this is clarified in discussion of Joshua’s other answer, below)]
thank you both for your involvement in answering my question. I don’t mind at all that this little debate has occurred there are a lot of things for me to learn from all you guys are saying. and hopefully some other people will benefit from it