Порождающие паттерны GoF помогают управлять созданием объектов: делать код гибче, убирать жёсткие зависимости и упрощать масштабирование. Ниже — три базовых паттерна, которые чаще всего встречаются на практике.
Factory (Фабрика)
Используется, когда объект нужно создавать не напрямую через `new`, а через отдельный механизм выбора и инициализации.Когда применять:
- если тип создаваемого объекта зависит от условий
- если нужно скрыть сложную логику создания
- если система должна легко расширяться новыми типами объектов
Плюсы:
- уменьшает связанность кода
- упрощает замену реализаций
- делает код чище и удобнее для тестирования
Пример из практики:
создание разных способов оплаты: `CardPayment`, `SBPPayment`, `CryptoPayment`. Клиентский код работает через общий интерфейс, а фабрика решает, какой объект вернуть.Singleton (Одиночка)
Гарантирует, что у класса существует только один экземпляр, и даёт к нему глобальную точку доступа.Когда применять:
- для логгера
- для конфигурации приложения
- для менеджера подключения или кеша, если по архитектуре допустим единый экземпляр
Плюсы:
- контроль над единственным экземпляром
- удобно для shared-состояния
Минусы:
- усложняет тестирование
- создаёт скрытые зависимости
- часто превращается в антипаттерн при чрезмерном использовании
Важно:
Singleton стоит применять осторожно. Во многих случаях лучше явное внедрение зависимостей через DI, чем глобальный доступ 🛠️Builder (Строитель)
Нужен для пошагового создания сложного объекта, особенно если у него много параметров и опций.Когда применять:
- если у объекта длинный конструктор
- если есть обязательные и необязательные параметры
- если нужно собирать объект в разных конфигурациях
Плюсы:
- повышает читаемость
- избавляет от “телескопических конструкторов”
- делает создание объектов более контролируемым
Пример:
создание `ServerConfig`: хост, порт, SSL, таймауты, ретраи, логирование. Через Builder можно собирать конфигурацию поэтапно и без путаницы.
Как выбрать паттерн
- Factory — когда важен выбор типа объекта
- Singleton — когда действительно нужен один экземпляр
- Builder — когда объект сложный и собирается по шагам
Главная польза этих паттернов — не “писать по учебнику”, а решать реальные архитектурные проблемы: уменьшать хаос в коде, повышать расширяемость и делать систему понятнее для команды 💡
Подборку каналов про IT — с практикой, архитектурой, backend, frontend и карьерой — стоит посмотреть отдельно 👀