Як Singleton порушує принцип єдиної відповідальності (SRP)?

Singleton порушує принцип єдиної відповідальності (SRP), тому що поєднує в собі дві різні ролі, які мають бути розділені між різними класами:

#Роль бізнес-логіки

Наприклад, клас Logger відповідає за запис логів, ConfigManager - за зберігання налаштувань, Cache - за кешування даних. Це і є їхня основна відповідальність.

#Роль керування життєвим циклом

Singleton змушує ці самі класи самостійно контролювати своє створення, зберігати посилання на єдиний екземпляр і забезпечувати глобальний доступ до нього.

Такий дизайн робить клас занадто "розумним": він не просто вирішує задачу, а й керує собою. Це порушує принцип SRP, за яким клас повинен мати лише одну причину для зміни.

Коли одна частина системи має змінюватися через логіку, а інша - через спосіб ініціалізації, зміни в одному аспекті зачіпають інший. У результаті код стає менш гнучким, важче тестується і сильніше пов'язаний із глобальним станом, що суперечить ідеї чистої, модульної архітектури.