Примечание: в данной статье речь о использовании синглтона идет в контексте его использования в Unity C# проектах.
Одной из наиболее острых проблем, с которой сталкивается абсолютно каждый начинающий программист, это проблема зависимости классов или, иными словами, проблема обеспечения взаимодействия между классами. Более того, обеспечение между ними правильного взаимодействия - это задача, которая может создавать трудности даже более опытным программистам. Повсеместная актуальность этой проблемы стала причиной появления большого количества паттернов, которые решают или пытаются решать эту самую проблему.
В голову только начинающих программистов, которые не так давно начали предпринимать попытки правильно структурировать свой код по классам, обычно приходит в голову приписать везде, где можно и где нельзя, публичный модификатор, а при необходимости использования функционала какого-либо класса они начинают создавать ссылки на экземпляры типов своих классов и присваивать соответствующие значения в инспекторе. И, казалось бы, проблема зависимости классов решается подобной практикой. В большей степени, это действительно так, но новички, прибегающее к такому решению, полноценно закрывают глаза на всевозможные принципы правильности написания кода. Делаем вывод, что такой подход является наиболее примитивным и неверным с точки зрения большого количества наиважнейших принципов. Например, при подобной практике полноценно нарушается принцип инкапсуляции, а некоторые возможные ситуации могут приводить к нарушению сразу пары принципов SOLID (Принципы Dependency Inversion и SRP).
Как правило, следующим шагом в попытках решения проблемы зависимости является синглтон (от en. Singleton). Многие новички, которые ознакамливаются с данным паттерном, сразу начинают внедрять его во всевозможные классы своих проектов, думая, что такой подход является верным. Но мало того, что многочисленное использование синглтона является в корне неправильным с точки зрения правильности писания кода, так еще и само применение синглтона может приводить к проблемам, когда он не успевает проинициализироваться к моменту принятия попытки его использования, а также к проблемам с многопоточностью и тестированием. Помимо этого, синглтон может скрыть зависимости в вашем коде, что затрудняет понимание того, какие компоненты взаимодействуют друг с другом, а это может значительно затруднить отладку и тестирование.
Важно отметить, что эта статья и ей подобные не пытаются вбить вам, что за использование синглтона у программистов нужно отбирать компьютер. Если речь идет о использовании синглтона в отношении одного/нескольких классов в небольшом unity проекте, то в этом нет ничего плохого. Скорее наоборот, такая практика будет являться более простым и правильным решением, опять же, когда речь идет о небольших проектах. Безусловно, на сегодняшний день существуют такие прекраснейшие паттерны, как Service Locator и DI контейнер, которые при правильном использовании могут раз и навсегда решить проблему зависимости в отношении ваших проектов. Но когда речь заходит о небольших проектах, внедрение и дальнейшее использование этих паттернов принесет вам слишком много головной боли как для проекта такого уровня, поскольку использование реализации условного DI контейнера влечет за собой необходимость поддерживать крупные блоки кода, отвечающие за инициализацию, инъекцию зависимостей, а также обработку связанных с ними ошибок. Переходя на более простой язык, можно обобщить, сказав, что использование DI контейнера и/или Service Locator потребляет больше памяти и/или ресурсов вашего компьютера, поэтому их использование в малых проектах часто может быть не оправдано.
Какие общие выводы можно сделать на основании данной статьи? В первую очередь, обобщим то, что использование синглтона в качестве основного паттерна для решения проблемы зависимости классов является одним из наихудших решений, которые можно принять. Рассматривать синглтон, сидя на фоне компьютера со своим проектом, лучше всего тогда и только тогда, когда вы умеете использовать его правильно и когда его использование планируется в отношении небольшого, незначительного проекта.