So, I’ve been pondering this question for quite some time as I am a self taught developer, and outside the scope of scripting inside of Unity, my knowledge is pretty lackluster in terms of software engineering.
I’ve read my share of books with design principles, and can see why singleton design patterns and the use of static variables and the like are a bad choice in terms of flexibility, debugging code, and being thread safe etc… In direct relation to Unity though, is it all that bad?
Take for example, I’m working on another prototype to showcase, and the UI that I am creating has a lot of instances where that particular UI will only have one instance of itself. In turn, the UI text will be populated by properties of a “Client” object, which in turn will of course not inherit a singleton pattern because of the re-use of said object. So, the script that is attached to a GameObject managing a certain “panel” of UI ( that has several components that aren’t duplicated and will not be ) has several static variables that can be edited by accessing the class name and not the cached component name, as it won’t ever be instantiated that way.
I can see how things can go awry if I were making use of this class and instantiating in several places, but I’m not. I don’t really have the experience to determine if there is a better way of managing these one-off instances of UI, and if using static variables is appropriate in this situation where I’m certain I don’t need to re-use the class. Is this a normal practice in this particular situation inside the scope of scripting with Unity, or in general, game development? I don’t see the need to create a class and make locally available variables when I’m certain there is only one instance, and one access point for my particular situation ever.