Какой принцип SOLID нарушает использование Singleton и почему?

Использование Singleton выглядит удобным, но почти всегда имеет архитектурную цену. Чтобы понять, какие именно принципы SOLID он нарушает, важно рассмотреть его влияние на код.

Нарушение Single Responsibility Principle (SRP)

Определение:
Single Responsibility Principle — у класса должна быть одна причина для изменения.

Singleton обычно совмещает несколько ролей:

• хранение состояния

• бизнес-логику

• контроль единственного экземпляра

• глобальную точку доступа

Это приводит к тому, что класс меняется по разным причинам:

• изменилась логика

• изменилась схема хранения

• изменилась стратегия жизненного цикла

В результате класс перестаёт быть изолированным и простым для сопровождения.

Нарушение Dependency Inversion Principle (DIP)

Определение:
Dependency Inversion Principle — зависимости должны строиться на абстракциях, а не на конкретных реализациях.

Singleton создаёт:

• жёсткую зависимость от конкретного типа

• скрытую зависимость (её нет в инициализаторе)

Пример проблемы:

• невозможно подменить реализацию в тестах

• сложно внедрить mock или stub

• код становится неявно связанным

Даже если Singleton реализует протокол, глобальный доступ (shared) всё равно фиксирует конкретную реализацию.

Почему это особенно проблемно в iOS

В iOS-приложениях Singleton часто используют для:

• NetworkManager

• Analytics

• Storage

• Session / Auth

Со временем такие объекты:

• разрастаются

• начинают знать слишком много

• используются «везде»

Это ухудшает:

• тестируемость

• читаемость

• контроль зависимостей

Когда Singleton допустим

Singleton может быть оправдан, если:

• объект действительно уникален по природе (например, UIApplication)

• он не содержит бизнес-логики

• его легко заменить через абстракцию