Factory
- Что это: порождающий паттерн, инкапсулирующий создание объектов и скрывающий конкретные классы от клиента.
- Где полезен: когда есть несколько взаимозаменяемых реализаций и выбор конкретного типа зависит от конфигурации, платформы, контекста (плагины, разные драйверы/адаптеры, фабрики в DI/модульной архитектуре), при создании тестируемых объектов (мока/стабы), при контроле жизненного цикла и кэшировании экземпляров.
- Когда избыточен/вреден: в простых проектах с единственной реализацией, если фабрик слишком много (class explosion) или они лишь переводят прямой new в ещё один уровень вызовов; когда скрываются явные зависимости — усложняется анализ кода и внедрение зависимостей; когда фабрика сама становится тонущим god-object.
- Признаки переусложнения: нет вариативности создаваемых типов, фабрика делает только один trivial new, сложности с отладкой/рефакторингом.
- Альтернатива/смягчение: прямая инициализация через конструктор, DI-контейнеры, Builder для сложной конфигурации, Prototype для клонирования.
Observer
- Что это: поведенческий паттерн «издатель-подписчик», отделяет источник событий от обработчиков.
- Где полезен: UI/фреймворки (события интерфейса), реактивный поток данных, уведомления в микросервисах (через event bus), плагинные системы, синхронизация состояния между модулями (MVC/MVVM).
- Когда избыточен/вреден: когда связь однозначна и синхронна (простой callback или прямой вызов понятнее), при большом числе подписчиков без контроля — утечки памяти (незакрытые подписки), трудно отлаживаемом побочном поведении (неявный поток управления), проблемах с порядком и консистентностью при асинхронном распространении событий.
- Признаки переусложнения: события используются лишь в одном месте, невидимые побочные эффекты, тяжело отследить цепочки уведомлений.
- Альтернатива/смягчение: явные колбэки/вызовы методов, очередь задач/command pattern, явные события через message broker с явным контрактом, использование слабых ссылок/автоматического отписывания.
Strategy
- Что это: поведенческий паттерн, инкапсулирующий семейство алгоритмов за единым интерфейсом, позволяя менять их в рантайме.
- Где полезен: когда требуется выбирать алгоритм выполнения в зависимости от контекста (разные алгоритмы сортировки/кэширования/шифрования/ценообразования), для тестирования/расширяемости, когда нужно убрать громоздкие условные операторы и изолировать вариации поведения.
- Когда избыточен/вреден: если существует только один алгоритм или стратегии очень мелкие и создают пачку одноразовых классов; если стратегии требуют доступа к внутреннему состоянию контекста и начинают ломать инкапсуляцию; когда переключение стратегии не нужно во время выполнения — лишняя абстракция.
- Признаки переусложнения: один клиент + одна реализация, сложная конфигурация классов ради простой ветвистости, негативное влияние на читаемость.
- Альтернатива/смягчение: передача функций/замыканий (higher-order functions), использование параметров/флагов, Template Method, объединение близких стратегий или применение композиции вместо наследования.
Краткое практическое правило
- Используйте паттерн, когда он решает реальную проблему: вариативность реализаций, необходимость расширяемости или слабой связанности. Избегайте, если паттерн вводит скрытую сложность при отсутствии вариативности.