intermediate
Singleton
Ограничивайте service одним shared instance только когда global lifecycle intentional, testable и безопаснее explicit injection.
Singleton ограничивает класс одним экземпляром — часто для process-wide registries, connection pools или configuration readers. В современных приложениях его часто заменяют DI-контейнеры с явным lifetime. Принимайте Singleton только когда глобальная уникальность — реальный инвариант, а тесты могут сбросить или подменить экземпляр.
На интервью: почему Singleton усложняет тесты и параллельный прогон. Сравните с module-level constants и DI-scoped services.
Типовые ошибки: скрытое глобальное mutable state; гонки lazy initialization; Singleton вместо проектирования границ.
Компромисс — гибкость против сложности: знайте, когда достаточно более простого пути.
Чеклист:
- Обоснуйте одну instance на процесс.
- Подмена в тестах должна быть возможна.
- Без бизнес-логики внутри Singleton holders.
- Предпочитайте framework-managed scopes.