Паттерны проектирования: Abstract Factory

Где встречается

• в кросс‑платформенных UI‑фреймворках (React Native, Flutter);
• в системах с темами оформления (светлая/тёмная тема);
• при работе с разными СУБД (MySQL/PostgreSQL/SQLite);
• в игровых движках (разные наборы спрайтов для платформ);
• в сервисах мультирегиональности (разные правила для стран).

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

Abstract Factory — порождающий паттерн, который:

1. Создаёт семейства взаимосвязанных объектов без указания их конкретных классов.
2. Определяет интерфейс для создания групп продуктов.
3. Позволяет легко переключаться между семействами через подклассы‑фабрики.

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

• абстрактный интерфейс фабрики с методами для каждого типа продукта;
• конкретные фабрики реализуют создание всех продуктов семейства;
• продукты одного семейства имеют общий интерфейс;
• клиентский код зависит только от абстрактной фабрики и интерфейсов продуктов.

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

Пояснения:

• GUIFactory — абстрактная фабрика с методами для всех типов продуктов.
• WindowsFactory и MacOSFactory — конкретные реализации, создающие согласованные семейства.
• Клиентский код (renderUI) работает только с абстрактными интерфейсами.

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

1. Система тем оформления

Почему это Abstract Factory:

• создаёт согласованное семейство объектов (цвета + типографика);
• изолирует клиентский код от конкретных реализаций;
• позволяет легко добавлять новые темы.

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

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

• строгая типизация всех интерфейсов;
• гарантия реализации всех методов;
• удобная работа с типами в клиентском коде.

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

• UI‑библиотеки (Material UI, Ant Design) — создание компонентов для разных тем.
• ORM (TypeORM, Prisma) — разные драйверы для СУБД.
• API‑клиенты — адаптация под разные версии API.
• Тестовые фреймворки — создание моков для разных окружений.
• Мультирегиональные сервисы — локализованные правила валидации.

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

Проверяют понимание:

• как создавать согласованные наборы объектов;
• чем отличается от Factory Method (создаёт семейства, а не одиночные объекты);
• как обеспечить взаимозаменяемость семейств.

Типичные вопросы:

1. В чём преимущество Abstract Factory перед набором отдельных фабрик?
   Ответ: гарантирует согласованность семейства объектов.
2. Как добавить новое семейство продуктов (например, Linux‑интерфейс)?
   Ответ: создать новую фабрику и реализовать все методы.
3. Можно ли комбинировать с другими паттернами?
   Ответ: да, например, с Singleton для фабрик.

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

1. Избыточная сложность
   Проблема: внедрение для 1–2 типов продуктов.
   Решение: использовать только при наличии семейств объектов.
2. Жёсткая иерархия интерфейсов
   Проблема: изменение интерфейса продукта требует правки всех фабрик.
   Решение: применять принцип открытости/закрытости (OCP).
3. Трудности тестирования
   Проблема: необходимость мокировать целые семейства.
   Решение: использовать dependency injection для фабрик.
4. Утечки памяти
   Проблема: фабрики хранят ссылки на созданные объекты.
   Решение: реализовывать методы очистки.

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

• когда система должна работать с семействами связанных объектов;
• при необходимости легко переключаться между наборами продуктов;
• для изоляции клиентского кода от конкретных реализаций;
• в кросс‑платформенных приложениях;
• при разработке плагинов/расширений с согласованным API.

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

• для создания одиночных объектов (лучше Factory Method);
• если семейства объектов не связаны между собой.