koobas.hobune.stream
Singleton vs. Static
I know this issue probably has been brought up many times, however, I am not sure my specific concerns were addressed very clearly.
I have been using Singletons a lot and it has made my life a lot easier. From what I've read, one of the major potential problems with singletons is that they may not be thread safe. For one thing, I am not doing multi-threading or web development; for another, the singleton script from Unity Wiki seems to be thread safe (it came with a lock). So, I stayed with it, despite of people's warning "the singleton pattern has been abused...", what exactly do they mean by that any way?
So I've singletoned. The Instance keyword is a little cumbersome, but the main thing is that I feel like an amateur. Not that I am not, but I want to be as professional as I can. When I look at professional packages, what is private, public, or static, is all very clear.
So, I decided to be professional and replace some of my singletons with static and I faced some major obstacles:
Static attributes and properties are not exposed to the inspector. To get around it I had to use additional variables and assign the value using Awake().
Data binding becomes very difficult. It is doable, but extra work is required.
So, the consequence was that I got a ton of extra variables and spent a lot of time deciding which ones are private, public, or static, all the while making sure that they can accomplish what I have already accomplished very easily with singletons.
This begs the question, is it worthy it? Does the convenience of singletons come with a price? Does it totally do away with Static? Should we embrace Singleton?
The thread safeness is not the real concern about singletons. The actual dangerous / evil "part" of a singleton is it's "staticness". It makes no difference if you use static variables or one static variable which holds an instance of a class (which is a singleton). Both store data statically which introduces global state into your program.
You might want to read those:
The problem with singetons / static variables is that if you write a component that uses those, it's behaviour becomes hard to test and sometimes leads to unpredictable results. Also if you want to reuse the component half a year later you usually don't remember what hidden dependencies the component has. It's not obvious since the access happens somewhere behind the scenes. For example: you just want to use a flashlight script you've written a long time ago and suddenly there's an instance of a player script which you don't use but the flashlight uses a player singleton behind the scene. That could generate huge chains of classes which are secretly linked together.
It also complicates debugging, makes it very difficult to turn the game into a multiplayer game and makes it almost impossible to test the class itself in a testing environment. In small projects that might not be such a big deal, but if the project gets larger you'll lose track of what's going on, where and when.
ok. I get it. So if I am using Static I might as well use Singleton.
I know I haven't been heeding the warning against globals, I have to really think about that. Thanks for the re$$anonymous$$der. I'll keep "Dependency Injection" in $$anonymous$$d.
I am very grateful for getting some answers and professional insights here.
One more question: does Toolbox avoid the pitfalls of Singleton?
