Factory
- Что: абстрагирует создание объектов — фабрика инкапсулирует логику выбора конкретного класса и подготовки экземпляра.
- Когда оправдано: когда код зависит от интерфейса/абстракции, набор конкретных продуктов может расти или меняться во время выполнения, нужно отделить конфигурацию/параметры создания от использования, или требуется централизовать создание (например, создание разных продуктов по конфигурации, плагинах, тестовая подмена).
- Преимущества: уменьшает связность, упрощает тестирование, локализует изменения в коде создания.
- Когда избыточно/вредит: если продуктов немного и они редко меняются, фабрика добавляет уровень абстракции без пользы; простая конструкция new A(...) понятнее; плохая фабрика (бог-фабрика) усложняет код и затрудняет понимание.
- Совет: предпочесть простую фабрику/фабричный метод для небольших вариаций; для большого числа типов — рассмотреть реестр/DI-контейнер вместо множества if/switch.
Observer
- Что: объекты подписываются на события/изменения состояния издателя; издатель оповещает подписчиков.
- Когда оправдано: нужно реактивное уведомление множества зависимых компонентов при изменении состояния (GUI, событийные системы, pub/sub, decoupling между модулями).
- Преимущества: слабая связность между издателем и подписчиками, легко добавлять/удалять слушателей, поддерживает асинхронность.
- Когда избыточно/вредит: простые последовательности вызовов превращаются в трудноотслеживаемые цепочки событий (implicit control flow), возникают проблемы с отладкой, порядком уведомлений, временем жизни слушателей (утечки памяти, если не отписываться). Для синхронных однократных связей лучше прямой вызов.
- Совет: документировать порядок и гарантии доставки; использовать слабые ссылки или явную отписку; для простых сценариев избегать.
Strategy
- Что: инкапсулирует алгоритм в отдельный объект (стратегию) и делает их взаимозаменяемыми в клиенте.
- Когда оправдано: требуется выбирать один из нескольких алгоритмов во время выполнения, нужно менять поведение без изменения клиента, нужно тестировать алгоритмы отдельно.
- Преимущества: упрощает расширение, уменьшает условные операторы внутри алгоритма, улучшает тестируемость.
- Когда избыточно/вредит: если есть только один алгоритм или отличия тривиальны — добавление интерфейса и классов усложняет дизайн; если алгоритмы сильно пересекаются, может быть проще использовать параметры или конфигурацию внутри одного класса.
- Совет: применять, когда ожидается рост числа алгоритмов или необходимость подмены поведения; для малых вариаций — стратегия как функция/замыкание часто проще.
Singleton
- Что: гарантирует единственный экземпляр класса и глобальную точку доступа.
- Когда оправдано: очень редкие системные ресурсы с действительно единственной сущностью (низкоуровневые менеджеры, драйверы), где создание дополнительного экземпляра действительно вредно и это контролируется централизованно.
- Преимущества: простой доступ к общему состоянию.
- Когда избыточно/вредит: зачастую ведёт к глобальному состоянию, затрудняет тестирование (магические зависимости), скрытой связности, проблемам с параллелизмом и порядком инициализации; часто лучше использовать зависимость через параметры/DI-контейнер или явно управлять жизненным циклом.
- Совет: избегать Singleton как «удобный глобальный объект». Если нужен один экземпляр — предпочтительнее управлять этим через контейнер зависимостей и явную конфигурацию; при реализации учитывать потокобезопасность и ленивую инициализацию.
Краткие практические рекомендации
- Применяйте паттерн когда он решает конкретную проблему: расширяемость, уменьшение связности, подмена в тестах, управление созданием или реактивность.
- Не применяйте «про запас» — лишние абстракции усложняют чтение и сопровождение.
- Рассматривайте более простые альтернативы: параметры/функции вместо стратегий, явные вызовы вместо observer, DI вместо singletons, конфигурация/фабричный регистр вместо тяжелых фабрик.