Singleton in Unity3D
Foreword
Hello, dear users of Habr. This publication will focus not so much on the rules for using Singleton , but on my vision of this pattern.
I want to warn that I am completely green. I am not a programming guru, not a senior and perhaps not even middle. I have an adequate development experience exclusively in Unity, therefore I affect only this environment. Initially, it was scary to share my thoughts, but remembering that sometimes
Why hate the Singleton pattern
The reasons are incredibly many, while it became clear to me that many of them are taken absolutely from the air, in an attempt to show themselves as the brave defender of the SOLID code.
Let's take a look at some of them!
Violation of the principle of sole responsibility. Sorry what? For what reason does our Loner with 100% probability violate this principle? The fact that a class has a global access point does not transfer it to the category of a GOD class. SoundManager? NetworkManager? SceneManager? Even in the official Unity3D tutorial, SoundManager was created by Singleton. Apparently, this item disappears.
Singleton is impossible to test.In other words, the argument of people is that the Loner is strongly connected with the object, it is initially stored in memory and it is impossible to run the test, excluding it from the application. Perhaps for people who do not understand the life cycle of the MonoBehaviour class, this will be so. But let's talk about cleanliness. The fact that our only instance is created in the Awake () method does not mean that this is a prerequisite for creating a Singleton. You can wrap its initialization in any other method and create it only when you first need it. In addition, people for some reason say that Singleton is
Close connection. Having written thousands of lines of terribly related code, I understand like no one what it is to suffer from bugs that appear in some class when changing another. But do you think Singleton is the source of this problem? Me not. Design, and again design. One of the articles (sorry, I can’t provide a link, because I read it incredibly long ago) said that you need to devote up to 80% of the time to designing the structure of the application, after which things will go like clockwork. I absolutely agree with that.
In fact, I’ll tell you more, I’m fanatical about modularity . To think over and create a structure in which each module will be self-sufficient, expandable and simple - my dream is in terms of programming at the moment.
Today I watched an incredibly informative presentation about using Scriptable Objects. It's called "Unite Austin 2017 - Game Architecture with Scriptable Objects." The material will be useful to every Unity developer. The speaker equated Singleton with natural disasters, nuclear war, and said that their studio is trying to create prefabs in games that are self-sufficient and have no close ties. I repeat, in my opinion - the solution is excellent. But what if our game requires connections?
One of the main examples of using Scriptable Objects is the Heart Stone game, which, as you may know, is partially made on Unity3D. Cool. Perfectly. Amazing. Only one big "BUT" bothers. Creating cards for Heart Stone may be limited to a plate in Excel, where we hammer in the name of the card, its description, mana, attack, and of course hit points. Done. And you needed to create a game in which everything is tied to generation. The landscape is generated, objects are generated, characters are generated, even that which is responsible for generation is generated. The pattern of one of the factories? Builder? Well, maybe. Our sensei are unlikely to lie. The disadvantages of these patterns are the overload of extra code and its overall complication. In no case do I say that you need to abandon the use of any patterns except Singleton,
Some additions
Often we can see solutions that look quite like “not singleton”. Developers are perverted by any means. They make a public variable for the class by dragging and dropping in the inspector the only object with the desired class onto the hundreds of other objects that need this link. Invoked in the Start () method of GameObject.Find (). But not Singleton, great, right? There is connectedness, there is no antipattern. Wonders.
MainSingleton's problem among novice developers is that you don’t have to think hard about the structure. Because of what, all code is overgrown with Loners. Access to any method without links, monolithic architecture. All this is bad, but everyone writes the code to the best of their literacy. We will be honest. Programming is not just a type of activity, it is a complete change in the way of thinking. It is impossible to read a 700-page book, to sit down and make perfect architecture. All comes with experience. And if your journey began with monoliths - this is not at all a reason to despair. Understanding a problem is the first step to solving it!
AlsoOveruse of Singleton's is absolutely identical to overuse of any other pattern. No one will give you a cookie for making an abstract factory and 30 interfaces for a class whose only purpose is to change the background image.
Seven times measure cut once!
Perhaps if the comments are very rich, I can supplement this article or even do part 2. I will hope for criticism of my writings. Thank you all for your attention!