Почему Singleton называют антипаттерном?

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

1. Глобальное состояние: Singleton создает глобально доступную точку состояния. Это нарушает инкапсуляцию, делает поведение системы неявным и сильно усложняет модульное тестирование, так как состояние сохраняется между тестами.
2. Жесткая связность (Tight Coupling): Классы напрямую обращаются к Singleton.Instance, что делает их зависимыми от конкретной реализации, а не от абстракции. Это нарушает Dependency Inversion Principle (DIP).
3. Нарушение Single Responsibility Principle (SRP): Класс начинает отвечать и за свою основную логику, и за управление своим жизненным циклом (гарантию единственного экземпляра).
4. Проблемы в многопоточных и распределенных системах: Наивная реализация не потокобезопасна. Даже потокобезопасные реализации могут стать узким местом (contention). В распределенных системах (микросервисы, веб-ферма) понятие "единственного экземпляра" теряет смысл.

Пример проблемной реализации:

// Классический небезопасный и проблемный Singleton
public class ProblematicLogger
{
    private static ProblematicLogger _instance;
    private ProblematicLogger() { } // Закрытый конструктор

    public static ProblematicLogger Instance
    {
        get
        {
            // НЕ ПОТОКОБЕЗОПАСНО! Может создать несколько экземпляров.
            if (_instance == null)
            {
                _instance = new ProblematicLogger();
            }
            return _instance;
        }
    }
    public void Log(string message) { /* ... */ }
}
// Использование создает жесткую связь.
ProblematicLogger.Instance.Log("Message");

Современные альтернативы (что использовать вместо Singleton):

• Внедрение зависимостей (Dependency Injection): Это основной способ. Зарегистрируйте сервис как AddSingleton<TService, TImplementation>() в контейнере DI (например, в ASP.NET Core). Контейнер сам управляет жизненным циклом единственного экземпляра и внедряет его как зависимость.

  // Регистрация в Program.cs
  builder.Services.AddSingleton<ILogger, FileLogger>();
  
  // Использование через внедрение зависимости
  public class OrderService
  {
      private readonly ILogger _logger; // Зависимость от абстракции
      public OrderService(ILogger logger) => _logger = logger; // Внедрение
      public void ProcessOrder() => _logger.Log("Processing...");
  }

• Явное создание экземпляра на верхнем уровне приложения (в Main или Startup) и передача его вручную.
• Фабричные методы, которые могут контролировать создание экземпляров.

Вывод: Сам по себе паттерн "один экземпляр на всё приложение" — полезная концепция. Антипаттерном является его реализация через статическое глобальное свойство. Используйте контейнеры DI для корректного управления жизненным циклом таких объектов.