Кратко по каждому паттерну: описание, пример, когда оправдан и когда превращается в лишнюю сложность.
Factory (Simple / Factory Method / Abstract Factory)
- Что: скрывает логику создания объектов, возвращая интерфейс/абстракцию вместо конкретного класса.
- Пример (псевдокод):
class Creator { Product create(type) { if (type=="A") return new A(); else return new B(); } }
- Когда оправдан:
- создание объектов сложное или зависит от конфигурации/платформы/времени выполнения;
- нужно подменять реализации для тестов или расширять семейства продуктов без изменения клиента;
- требуется инкапсуляция логики выбора конкретной реализации.
- Когда избыточен:
- всего одна-две реализации и простые конструкторы;
- клиенту не важна абстракция — прямой вызов new проще и понятнее;
- если фабрика только перенаправляет вызов без упрощения или инкапсуляции.
- Подсказка: для небольших проектов и малого количества типов фабрика часто усложняет код.
Observer (Publisher–Subscriber / Listener)
- Что: объект (publisher) уведомляет подписчиков об изменениях состояния, подписчики регистрируются/отписываются динамически.
- Пример: UI: модель изменяется → все слушатели (view, логгеры) получают событие.
- Когда оправдан:
- множество независимых компонентов должны реагировать на одно событие;
- нужна слабая связность между источником событий и обработчиками;
- асинхронная обработка событий, GUI, событийные системы.
- Когда избыточен/опасен:
- единственный получатель — лучше прямой вызов;
- сложности с отпиской/жизненным циклом (утечки памяти, если подписчики живут дольше);
- при строгом порядке вызовов/побочных эффектах проще явно вызвать обработчики.
- Замечание: контролируйте владение ссылками (weak refs) и потокобезопасность.
Strategy
- Что: инкапсулирует алгоритм в отдельный объект и делает их взаимозаменяемыми.
- Пример: SortStrategy { sort(list) } — QuickSort, MergeSort, HeapSort; клиент выбирает стратегию.
- Когда оправдан:
- набор алгоритмов для одной операции, выбор зависит от контекста (производительность, конфигурация);
- упрощает тестирование и расширяемость (добавление нового алгоритма без изменения клиента);
- уменьшает ветвления (if/else/switch) в коде.
- Когда избыточен:
- один алгоритм или различия несущественны;
- накладные расходы от создания объектов-стратегий и косвенных вызовов не оправданы.
- Совет: если вариаций мало и они редко меняются, простой параметризированный метод проще.
Decorator
- Что: динамически добавляет объекту новые обязанности, оборачивая его в другие объекты того же интерфейса.
- Пример: InputStream → BufferedInputStream → CipherInputStream в Java.
- Когда оправдан:
- нужно комбинировать поведения гибко в рантайме (композиция многих независимых опций);
- избежать экспоненциального роста подклассов при комбинировании функций.
- Когда избыточен:
- небольшое число фиксированных вариантов — проще наследовать или использовать флаги/параметры;
- слишком глубокие цепочки декораторов ухудшают дебаг и читаемость.
- Математическое замечание: если есть $k$ независимых опций, то явное создание подклассов для всех комбинаций ведёт к $2^k$ классам — декоратор позволяет составлять комбинации без экспоненциального роста.
Общие критерии выбора
- Применяйте паттерн, если он решает реальные проблемы: расширяемость, тестируемость, повторное использование, снижение связности.
- Избегайте паттернов ради паттерна: они добавляют уровни абстракции, косвенные вызовы и усложняют понимание.
- Оцените количество вариаций/комбинаций, требования к времени выполнения и поддержке: если выигрыша от гибкости нет, проще и понятнее — прямой код.
- Документируйте почему выбран паттерн — это помогает избежать "скрытой" сложности для команды.