Singleton
- Идея: обеспечить единственный экземпляр класса и глобальную точку доступа.
- Когда полезен: нужен один ресурс/контекст в приложении (настройки, пул соединений) и создание контролируемо.
- Минусы: глобальное состояние затрудняет тестирование, скрытая зависимость, проблемы с многопоточностью.
- Альтернативы: внедрение зависимостей (DI), модуль/namespace с экспортируемым экземпляром, явный объект-конфиг, фабрика, передача контекста.
Factory Method / Simple Factory
- Идея: инкапсулировать логику создания объектов в методе/классе.
- Когда полезен: создание объектов зависит от конфигурации, типа или скрытой логики; нужно избежать раскрытия конкретных классов.
- Минусы: может привести к множеству классов-фабрик и усложнить поток создания.
- Альтернативы: конструкторы/статические фабричные методы, DI-контейнер, передачa функции-фабрики (higher-order function).
Abstract Factory
- Идея: семейства взаимосвязанных объектов создаются согласованно (интерфейс для фабрик).
- Когда полезен: нужна взаимосвязь между продуктами при переключаемых реализациях (темы, платформы).
- Минусы: избыточен при 1–2 реализациях; усложняет добавление нового продукта.
- Альтернатива: отдельные фабрики, конфигурация с DI, проброс зависимостей.
Builder
- Идея: поэтапное построение комплексного объекта (позволяет читаемо задавать параметры).
- Когда полезен: много необязательных параметров, сложная валидация, иммутабельность итогового объекта.
- Минусы: лишняя прослойка для простых классов.
- Альтернатива: именованные/опциональные параметры языка, статические фабрики, комбинация конструктора + объект конфигурации.
Prototype
- Идея: клонирование конфигурируемых экземпляров вместо создания с нуля.
- Когда полезен: дорогостоящая инициализация объектов или множество схожих экземпляров.
- Минусы: сложность клонирования (глубокого/поверхностного), управление состоянием.
- Альтернатива: фабрики, реинициализация нового экземпляра, copy-on-write.
Observer / Publish–Subscribe
- Идея: объекты подписываются на события издателя и получают уведомления при изменениях.
- Когда полезен: слабосвязанная коммуникация между компонентами, GUI, событийные системы.
- Минусы: труднее отследить поток выполнения, возможны утечки памяти (неотписавшиеся слушатели), порядок уведомлений неочевиден.
- Альтернативы: явные колбэки/обратные вызовы, реактивные библиотеки (Rx), потоки/каналы, polling, прямой вызов методов.
Strategy
- Идея: инкапсулировать взаимозаменяемые алгоритмы и выбирать их во время выполнения.
- Когда полезен: множество алгоритмов с одинаковым интерфейсом, необходимость менять поведение.
- Минусы: может привести к множеству маленьких классов; избыточен если алгоритм простой.
- Альтернативы: функции/замыкания (в языках первого класса функций), условные операторы при небольшом числе вариантов.
Adapter
- Идея: привести интерфейс существующего класса к нужному клиенту.
- Когда полезен: интеграция несовместимых интерфейсов без изменения исходного кода.
- Минусы: если можно изменить реализацию клиента или поставщика, адаптер — лишняя прослойка.
- Альтернатива: рефакторинг интерфейса, фасад, обертка в месте использования.
Decorator
- Идея: динамически добавлять поведение объекту, оборачивая его.
- Когда полезен: добавление кросс-сечений поведения (логирование, кэш) без изменения класса.
- Минусы: много обёрток усложняет трассировку; порядок декорирования важен.
- Альтернатива: композиция с явным вызовом вспомогательных функций, наследование (с осторожностью), аспекты (AOP).
Facade
- Идея: упростить сложную подсистему единым интерфейсом.
- Когда полезен: скрыть сложность, упростить использование библиотеки.
- Минусы: фасад может стать богом-объектом если накапливает слишком много ответственности.
- Альтернатива: разбить подсистему на понятные модули, документировать непосредственные API.
Command
- Идея: инкапсулировать запрос в объект (undo/redo, очередь задач).
- Когда полезен: очередь операций, логирование/отмена, отложенное выполнение.
- Минусы: увеличивает число классов; сложнее, если команды простые.
- Альтернативы: функции/делегаты, сообщения/события, транзакции на уровне сервиса.
Iterator, Composite, MVC/MVP/MVVM и др.
- Коротко: Iterator упрощает перебор коллекций; Composite позволяет работать с деревьями через единый интерфейс; MVC и пох. разделяют представление, логику и данные.
- Альтернативы: встроенные итераторы языка, простые списки/рекурсия, более простые архитектурные разделения.
Когда паттерн улучшает архитектуру
- Решает повторяющуюся архитектурную проблему: делает намерение явным, повышает повторное использование.
- Улучшает тестируемость и заменяемость компонентов (особенно вместе с интерфейсами/DI).
- Облегчает масштабирование и расширение (open/closed).
- Помогает команде понять архитектуру при единообразном использовании паттернов.
Когда паттерн ведёт к чрезмерной сложности
- Преждевременное применение: паттерн решает несуществующую проблему.
- Паттерн добавляет уровни абстракции без явной выгоды — ухудшается читаемость и отладка.
- Малый проект/простая задача: явные простые решения быстрее и понятнее.
- Когда команда не знакома с паттерном — поддержка страдает.
Правила выбора и практические советы
- Принцип KISS: сначала простое решение; рефакторьте в паттерн по мере роста требований.
- Принцип YAGNI: не вводите абстракции заранее, если нет потребности.
- Предпочитайте композицию над наследованием.
- Используйте DI вместо глобального состояния (Singleton).
- В языках с функциями первого класса часто проще использовать функции/замыкания вместо классических паттернов.
- Документируйте намерение: почему паттерн применён, какие проблемы решает.
Короткие примеры альтернатив (сравнение)
- Singleton vs DI: вместо глобального доступа — передать экземпляр в конструкторе; мокать в тестах.
- Factory vs конструктор: если логика создания простая — обычный конструктор; если сложная — фабрика/DI.
- Observer vs callback/stream: для простой связи достаточно callback; для сложных потоков — Rx/stream.
- Strategy vs функция: в JS/Scala/Python проще передать функцию-алгоритм вместо создания класса.
Итого: паттерны — инструменты, а не догма. Применяйте, когда они явно решают архитектурную проблему, повышают читабельность/тестируемость/расширяемость; избегайте их ради «красивости» или преждевременной абстракции.