Вопрос проверяет понимание скрытых обязанностей паттерна Singleton и его влияния на архитектуру.
Singleton часто нарушает принцип Single Responsibility, потому что он совмещает сразу несколько ролей. Он отвечает не только за бизнес-логику, но и за контроль своего жизненного цикла и глобальный доступ. В итоге класс начинает решать больше одной задачи. Это усложняет тестирование и поддержку. Из-за этого Singleton часто становится источником скрытой связности.
Проблема Singleton выходит за рамки его внешней простоты.
Singleton — паттерн, гарантирующий существование единственного экземпляра класса и предоставляющий глобальную точку доступа к нему.
Перед тем как рассматривать пример, важно понять, какие обязанности появляются у Singleton.
Singleton одновременно:
Реализует бизнес-логику
Управляет созданием экземпляра
Контролирует жизненный цикл
Предоставляет глобальный доступ
Каждая из этих обязанностей — отдельная причина для изменения.
class AnalyticsManager {
static let shared = AnalyticsManager()
private init() {}
func track(event: String) {
// логика аналитики
}
}
Класс отвечает и за аналитику, и за механизм глобального доступа.
сложнее подменять в тестах
невозможно иметь несколько экземпляров
зависимость неявная
Singleton нарушает SRP, потому что смешивает инфраструктурную и бизнес-ответственность в одном классе. Это допустимо в редких случаях, но требует осознанного применения.
