Factory (Factory Method / Abstract Factory)
- Что делает: инкапсулирует создание объектов, скрывая конкретные классы от клиента; Abstract Factory группирует набор взаимосвязанных фабрик.
- Когда оправдано: когда код зависит от абстракций, нужно менять семейства продуктов (платформы, плагины), создавать объекты с различной конфигурацией в разных окружениях (тест/прод/мока); при необходимости централизованной логики создания (кэширование, пул объектов).
- Когда ухудшает дизайн: если фабрика вводится преждевременно и просто оборачивает один-конструктор — лишняя абстракция; множество мелких фабрик усложняет навигацию; использование фабрик вместо простого конструктора или DI-контейнера создает ненужный уровень косвенности.
Singleton
- Что делает: гарантирует единственный экземпляр класса и глобальную точку доступа.
- Когда оправдано: редкие случаи с действительно единственным ресурсом в процессе (низкоуровневый менеджер ресурсов, binding к нативному API), когда создание нескольких экземпляров физически невозможно или очень дорого.
- Когда ухудшает дизайн: часто приводит к глобальному состоянию, затрудняет тестирование (неявные зависимости, трудно мокать), проблемам с инициализацией и потокобезопасностью; часто лучше использовать DI/контейнер, инстанцирование на уровне приложения или модульную область видимости вместо Singleton.
Observer (Publisher-Subscriber)
- Что делает: позволяет объектам подписываться на события издателя и получать уведомления при изменениях; снижает связность между компонентами.
- Когда оправдано: GUI/событийные системы, реактивные потоки, рассылка уведомлений между слабо связанными модулями, расширяемые плагины.
- Когда ухудшает дизайн: невидимые побочные эффекты, трудности отладки (порядок уведомлений, гонки), утечки памяти при ненадлежащем отписывании; если логика простая синхронная — лишняя асинхронная сложность; для широкомасштабной коммуникации лучше явные контракты или поток событий с контролем жизненного цикла.
Strategy
- Что делает: инкапсулирует алгоритм в отдельный объект, позволяет менять поведение в рантайме, реализует композицию вместо ветвления.
- Когда оправдано: несколько взаимозаменяемых алгоритмов (сортировки, валидации, ценообразование), нужно переключать стратегии в конфигурации или тестах, уменьшить большие условные операторы.
- Когда ухудшает дизайн: приводит к взрыву классов ради несложных ветвей; если стратегия используется только в одном месте и не предполагается расширение — проще использовать функцию/замыкание или единственный метод с ясной ветвью; излишняя абстракция усложняет понимание.
Короткие практические рекомендации
- Не применять паттерн «ради паттерна»: выбирайте, если решает конкретную проблему (расширяемость, тестируемость, инкапсуляция изменений).
- Предпочитайте простые решения: функции/замыкания, композиция, DI-контейнеры часто дают те же преимущества без шаблонной сложности.
- Обращайте внимание на тестируемость, ответственность классов и читаемость — если паттерн ухудшает эти показатели, вероятно, он не нужен.