Паттерны проектирования: Singleton.

Где встречается: кеширование данных, API‑клиенты, логирование, глобальные сервисы в React/Node.js.

🔍 Суть паттерна

Singleton — это порождающий паттерн, который гарантирует существование только одного экземпляра класса и предоставляет глобальную точку доступа к нему.

Ключевые признаки:

• Приватный конструктор (запрещает прямое создание экземпляров).
• Статический метод getInstance() для получения объекта.
• Хранит единственный инстанс внутри себя.

🛠 Базовый пример на JavaScript

💡 Реальные примеры в React

1. Кеширующий API‑клиент

Почему это Singleton:

• Один клиент на всё приложение.
• Кеширует ответы, избегая дублирующих запросов.
• Доступен из любого компонента.

2. Сервис логирования

🧩 Пример на TypeScript: строго типизированный Singleton

Плюсы TypeScript‑версии:

• Строгая типизация методов (get<T>).
• Приватные поля защищены от внешнего доступа.
• Компилятор поймает попытки new ConfigService().

🔎 Где ещё встречается в JS/TS

• React Context — провайдер контекста часто реализует Singleton‑логику.
• Redux Store — единственный инстанс хранилища.
• Библиотеки вроде Axios — по умолчанию используют один инстанс клиента.
• Браузерные API (localStorage, sessionStorage — глобальные синглетоны).

🧭 Зачем спрашивают на собеседовании?

1. Понимание инкапсуляции
   Как скрыть создание объекта?
   Почему приватный конструктор важен?
2. Управление состоянием
   Как гарантировать единый источник данных?
   Чем Singleton отличается от глобального объекта (window.myService)?
3. Тестирование и масштабируемость
   Как мокировать Singleton в тестах?
   Какие проблемы возникают при многопоточности (в Node.js)?
4. Архитектура
   Когда Singleton оправдан, а когда лучше Dependency Injection?
   Как избежать «божественного объекта» (God Object)?

⚠️ Нюансы и подводные камни

1. Глобальное состояние
   Синглтоны усложняют тестирование (зависимость от глобального инстанса).
   Решение: передавайте инстанс через пропсы или Context.
2. Утечки памяти
   Если синглтон хранит ссылки на компоненты, они не смогут освободиться.
   Решение: очищайте кэш при необходимости.
3. Проблемы в SSR (Server‑Side Rendering)
   В Node.js один инстанс может обслуживать несколько запросов — будьте осторожны с состоянием!
   Решение: используйте scoped‑синглтоны (по одному на запрос).
4. Нарушение принципа единственной ответственности
   Синглтон может превратиться в «мусорку» для всего подряд.
   Решение: разделяйте логику на мелкие сервисы.

✅ Когда применять Singleton?

• Кеширование данных (API‑ответы, вычисления).
• Глобальные сервисы (логирование, аналитика, конфигурация).
• Ресурсы с ограниченным доступом (соединение с БД, WebSocket).
• Фабрики (если нужен единственный создатель объектов).

❌ Когда не стоит использовать?

• Для простых утилит (лучше чистые функции).
• Если нужны несколько инстансов (например, разные конфигурации API).
• В микросервисах (нарушает изоляцию).
• Когда важно тестирование (сложно мокировать).

Что дальше?
В следующей статье разберём паттерн Factory Method с примерами из React (динамическое создание компонентов) и TypeScript (типизированные фабрики).

Хотите углубиться в какой‑то аспект (например, сравнение с Dependency Injection или реализацию в Redux)? Дайте знать!