Singleton in unity3d

Foreword

Good morning, dear users of Habr. In this publication we will discuss not so much about the rules for using Singleton , but about my vision of this pattern.

I want to warn you that I'm a completely green man. I am not a programming guru, not a gentleman, and it is possible that not even a middle one. I have adequate development experience exclusively in Unity, so far I only affect this environment. Initially, it was scary to share my thoughts, but remembering that sometimes serious uncles are published here, he decided to try. I love the users of this site, and even if my karma goes to the Mariana Trench, the comments will always help me to understand what I could not understand earlier and find the very truth!

Why hate the Singleton pattern

There are a lot of reasons, despite how it became clear to me, many of them are taken absolutely out of thin air, in an attempt to show themselves as a brave defender of the SOLID code.

Let's look at some of them!
')
Violation of the principle of sole responsibility. Sorry what? What is the reason why our Singleton with 100% probability violates this principle? The fact that a class has a global access point does not transfer it to the discharge of a GOD class. SoundManager? NetworkManager? SceneManager? Even in the official Unity3D SoundManager tutorial created by Singleton. Apparently, this item disappears.

Singleton cannot be tested. In other words, the argument of people is that the Singleton is strongly associated with the object, 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, everything will be so. But let's talk on 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 miraculously transmitted through the scenes. What is DontDestroyOnLoad used for? Riddle.

Close relationship . Having written thousands of lines of horribly related code, I, like no one, understand what it means to suffer from bugs that appear in a class when another one changes. But do you think Singleton is the source of this problem? Me not. Design, and again design. In one of the articles (sorry, I could not indicate the link, because I read it incredibly long ago) it was said that you need to devote up to 80% of the time to designing the structure of the application, after which it will go like clockwork. I absolutely agree with that.

Actually, I will tell you more, I am fanatical with respect to modularity . To think over and create a structure in which each module will be self-sufficient, expandable and simple - my dream in terms of programming at the current moment.

Today I watched an incredibly informative presentation about using Scriptable Objects. It is 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 was trying to create prefabs in games that were self-sufficient and did not have 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 probably know, is partially made on Unity3D. Cool. Perfectly. Delightful. Only one big "BUT" worries. Creating cards for Heart Stone can be limited to a table in Excel, where we hammer in the name of the card, its description, mana, attack, and of course, hit points. Is done. And you needed to create a game in which everything is tied up on generation. The landscape is generated, objects are generated, characters are generated, even what is responsible for generation is generated. The pattern of one of the factories? Builder? Well, maybe. Our sensei are unlikely to lie. The downside of these patterns is the overload of the code and its general complication. I do not in any way say that it is necessary to abandon the use of any patterns except Singleton, I just want to urge people not to be afraid of Singles and not to produce patterns where they are not needed, which can lead to an inappropriate complication of architecture.

Few additions

Often we can see solutions that look quite like “not singletons”. Developers are perverted by any means. Make a public variable for a class by dragging a single object in the inspector with the required class onto the other hundreds of objects that need this reference. Call in the Start () method GameObject.Find (). But not Singleton, great, right? There is a connection, there is no antipattern. Miracles.

The main problem of singleton among novice developers is that they do not need to think much about the structure. Because of what the whole code is overgrown with singles. Access to any method without references, solidity of the architecture. All this is bad, but everyone writes code to the best of their literacy. Let's be honest. Programming is not just a type of activity, it is a complete change of the way of thinking. It’s impossible to read a 700-page book, sit down and make an ideal architecture. All comes with experience. And if your path began with monoliths - this is not a reason to despair. Understanding the problem is the first step to solving it!

Also , excessive use of Singletons is absolutely identical to excessive use of any other pattern. No one will give you a cookie for what you make an abstract factory and 30 interfaces for the class, the only purpose of which is to change the background image.

Seven times measure cut once!

Perhaps, if the comments are very rich, I can add this article or even make part 2. I will hope for criticism of my writings. Thank you all for your attention!