Почему Singleton считают антипаттерном?

Singleton часто критикуют как антипаттерн из-за ряда архитектурных проблем, с которыми я сталкивался на практике:

1. Глобальное состояние и скрытые зависимости: Класс, доступный глобально через getInstance(), нарушает принципы инкапсуляции и внедрения зависимостей (DI). Это усложняет понимание того, от каких компонентов зависит ваш код, что особенно проблематично в больших приложениях.
2. Сложность тестирования: Из-за глобального состояния становится практически невозможно изолировать модульные тесты. Состояние, измененное в одном тесте, может «протекать» и влиять на результаты других.
3. Нарушение принципа единственной ответственности (SRP): Singleton часто становится «мусорным ведром» для функциональности, которая просто должна быть доступна в одном экземпляре, но логически не связана.
4. Проблемы в многопоточных средах: Требует дополнительной синхронизации (двойная проверка, мьютексы), что усложняет реализацию и может стать узким местом по производительности.

Пример проблемного Singleton на C#:

public sealed class ProblematicLogger
{
    private static ProblematicLogger _instance;
    private static readonly object _lock = new object();

    private ProblematicLogger() { }

    public static ProblematicLogger Instance
    {
        get
        {
            if (_instance == null) // Первая проверка (непотокобезопасная)
            {
                lock (_lock)
                {
                    if (_instance == null) // Вторая проверка
                    {
                        _instance = new ProblematicLogger();
                    }
                }
            }
            return _instance;
        }
    }
    // ... методы логирования
}

Альтернативы, которые я предпочитаю:

• Внедрение зависимостей: Зарегистрировать сервис как singleton в контейнере DI (например, в ASP.NET Core services.AddSingleton<ILogger, FileLogger>()). Это дает тот же жизненный цикл объекта, но без глобального доступа и со всеми преимуществами DI.
• Явная передача экземпляра: Создать экземпляр в корне приложения (в Program.cs или Startup.cs) и явно передавать его в зависимости через конструктор.

Singleton может быть оправдан для по-настоящему уникальных, неделимых ресурсов (например, доступ к физическому устройству), но в 95% случаев его стоит избегать в пользу DI.