Как синглтон становится общей точкой доступа
Обычно синглтон устроен так: класс сам хранит ссылку на свой единственный объект, а метод вроде `getInstance()` возвращает эту ссылку всем, кто её запрашивает. Первый вызов создаёт объект, последующие получают уже существующий. Так разные части программы обращаются к одному и тому же состоянию — например, к настройкам приложения или журналу событий.
Важно, что ограничение действует в пределах конкретного механизма выполнения программы. В многопоточном приложении два потока могут одновременно попытаться создать объект. Если создание не защищено, вместо одного экземпляра появятся два. Поэтому синглтон нужно инициализировать безопасно для параллельного доступа либо создавать заранее, до запуска рабочих потоков.
Удобство оборачивается скрытой зависимостью
Общая точка доступа избавляет от необходимости передавать объект через длинную цепочку вызовов. Но именно поэтому её легко начать использовать повсюду. Функция может обращаться к синглтону, хотя по её параметрам этого не видно: читателю приходится искать скрытый источник данных, чтобы понять поведение кода.
Такая связь усложняет проверку программы. Например, тест, которому нужны другие настройки или пустое хранилище, не может просто передать их при вызове функции — общий объект уже доступен всей системе. Состояние одного теста способно повлиять на следующий, если его не сбросить.
Когда общий экземпляр действительно полезен
Синглтон уместен, когда в приложении по смыслу должен существовать один общий объект и его жизненным циклом удобно управлять централизованно. Но если объект нужен многим компонентам лишь для удобства, явная передача зависимости обычно делает связи заметнее и облегчает замену объекта при тестировании.
Практическая цена синглтона — не только ограничение числа экземпляров: он превращает локальное решение о доступе к объекту в общее решение о состоянии всей программы. Чем больше кода на него опирается, тем труднее менять или независимо проверять отдельные части системы.
