- Порождающие
- Структурные
- Поведенческие
Помогают организовать гибкое создание сущностей(чаще объектов). Уменьшаю зависимости.
- Абстрактная фабрика (Abstract Factory)
- Строитель(Builder)
- Фабричный метод (Factory method)
- Прототип (Prototype)
- Одиночка (Singleton)
Паттерн позволяющий создавать семейства сущностей без жесткой завязки на конкретную реализацию(классы).
Применяю если в проекте есть семейства сущностей(наборы сущностей). Количество и тип сущностей в каждом наборе одинаковые, но различается реализация.
Набор 1:
- Кнопка
- Инпут
- Таблица
Набор 2:
- Кнопка Мобильная
- Инпут Мобильный
- Таблица Мобильная
Таким образом мы можем менять фабрику в зависимости от типа устройства(мобильное, десктоп). Таким образом мы только в одном месте определим какую фабрику выбрать и в других местах просто использовать ее.
Редко
Позволяет создавать сложные объекты пошагово.
Если мне необходимо формировать какой-то конфиг динамически, либо динамически нужно сформировать форму, либо я реализую степпер, где пользователь шаг за шагом заполняет большую форму. То я сразу смотрю в сторону билдера. Если нужно собрать сложный/большой объект - билдер.
Часто
Паттерн позволяющий подменять реализацию создаваемой сущности.
Фабрика набор методов для создания набора сущностей. Фабричный метод - метод для создания сущностей. Главное чтобы эти сущности описывались одним интерфейсом. Применяю тогда, когда у меня есть несколько сущностей, они взаимозаменяемые, нужно динамически их создавать, выбирая в зависимости от условий.
Редко
Паттерн позволяющий создавать сущность на основе другой сущности.
Применяю, когда мне необходимо создавать сущности по шаблону. Например: создание коллекции с фильмами. Создание формы фидбека и тд. У меня в проекте есть прототип, когда пользователь хочет создать новую коллекцию, написать новый отзыв, то я просто копирую прототип с дефолтными значениями и потом пользователь уже заполняет сам то, что нужно.
Средне
Паттерн позволяющий создать только один экземпляр.
Если я слышу, что что-то должно быть в единственном числе - синглтон. Один экземпляр движка плеера, одна фабрика создания рекламных баннеров, один логгер, один чат поддержки, один экземпляр сервиса(часто в DI).
Часто
Помогают организовать иерархие сущностей без лишних жестких зависимостей.
- Адаптер (Adapter)
- Мост (Bridge)
- Компоновщик (Composite)
- Декоратор (Decorator)
- Фасад (Facade)
- Легковес (Flyweight)
- Заместитель (proxy)
Паттерн позволяющий адаптировать реализацию под интерфейс без внесения в нее изменений.
Если у меня есть несколько реализаций чего-то(плеерных движков, логгеров и тп). Мне хочется чтобы в приложении с ними могли работать одинаково, чтобы специфичная логика не расползалась. Я реализую адаптеры, которые позволяют адаптировать эти реализации под интерфейс. Если я вижу, что мы ждём сущность соответствующую интерфейсу, но в библиотеки, которую мы используем эта сущность с другим интерфейсом, то я адаптирую ее под наш интерфейс. Там могут быть просто другие названия методов и тп. В адаптере будет логика адаптирования под наш интерфейс.
Часто
Паттерн позволяющий разделить реализацию и абстракцию на две иерархии, что позволяет их развивать независимо.
Если я вижу, что есть какой-то класс, сущность или модуль, но одна из его частей изменяется чаще других, то можно ее вынести и организовать взаимодействие на уровне интерфейсов, таким образом мы сможем менять реализацию этой части, подменять ее и тд без вреда для основной неизменяемой.
Средне
Паттерн позволяющий сгруппировать объекты в дерево и работать с ними как с одним.
Если я мне необходимо работать с графами, либо с структурой близкой к дереву, либо которую можно представить как дерево, то я сразу думаю о возможности использования этого паттерна.
Редко
Паттерн позволяющий добавить новой логики к уже имеющимся методам, реализации.
Если мне нужно гибко добавлять новую логику к уже имеющийся, то я могу либо сделать кучу ифаков, либо сделать декоратор, декоратор лучше, тк не усложняет логику и можно динамически менять декораторы.
Очень часто
Паттерн позволяющий просто работать со сложной реализацией или группой реализаций.
Если у меня есть сложный механизм, сложная реализация, иногда даже состоящая из нескольких частей, то я думаю о фасаде. Фасад позволяет скрыть сложность от пользователя(конечный пользователь, другие разработчики) и работать просто с чем-то сложным
Часто
Паттерн позволяющий экономить память и уменьшать сложность.
Если я замечаю, что у многих объектов есть одинаковая часть, которая и изменяется одинаково, например, пользователь, то я просто выношу пользователя в один объект и все остальные ссылаются на него, а не хранят каждый у себя.
Часто
Паттерн - секретарь. Позволяет сделать что-то до/после вызова реального метода объекта.
Если мне нужно гибко управлять доступом к частям объекта, то я выношу такую логику в проксю, что позволяет не усложнять сам объект. А в прксе уже идут проверки и тп. Еще проксе можно организовать логгирование, кеширование, предзагрузку и тп.
Средне
Помогают организовать гибкое взаимодействие между сущностями.
- Цепочка обязанностей (Chain of responsibility)
- Команда (Command)
- Итератор (Iterator)
- Посредник (Mediator)
- Снимок, сохранение (Memento)
- Наблюдатель (Observer)
- Состояние (State)
- Стратегия (Strategy)
- Шаблонный метод (Template method)
- Посетитель (Visitor)
Паттерн позволяющий разделить логику между обработчиками и выполнять ее последовательно.
Использую если нужно организовать логику сложной проверки. Ярким примером являются мидлвары в редаксе.
Средне
Паттерн позволяющий превратить действие в объект. Это позволяет организовывать очереди, логику отмены.
Использую если нужно фиксировать каждое действие пользователя, чтобы иметь возможность работать с историей. Яркий пример - работа с браузерным апи, каждый переход это команда, которая складывается в историю и мы можем вернуться на любой участок истории. (так работают почти все клиентские роутеры)
Средне
Паттерн позволяющий организовать обход коллекции, без знаний о ее внутренней структуре.
Если работаю с какой-то кастомной коллекцией(не массив), например linked list, queue и что-то подобное, то там реализую итератор, чтобы комфортнее и проще обходить их.
Средне
Паттерн позволяющий уменьшить связанность между несколькими сущностями.
Если у меня есть ворох объектов/сущностей/модулей и они взаимодействуют другом с другом напрямую, то в будущем это может привести к циклическим зависимостям, избыточной связанности и тп. В этих случаях я реализую сущность-посредник, который отвечает за работу с этими связями, а сами сущности работают только с ним.
Часто
Паттерн позволяющий делать сохранений объекта, прошлые состояния и восстанавливать их без погружения пользователя в детали реализации.
Если необходимо реализовать логику отмены изменений в рамках одного состояния/объекта, то я выберу снимок, а не команду, тк команда нечто более глобальное(затрагивает много частей, много состояний), снимок более локальное.
Редко
Паттерн позволяющий подписываться на изменений/события и сразу же реагировать на них.
Если необходимо следить за изменениями(стор редакса как пример), следить за событиями(браузерные ивенты) и тп, то тут этот паттерн отлично подходит, только не забывайте отписываться. Основная идея в том, что мы уходим от постоянного опрашивания, теперь нас оповещают о изменениях/событиях
Часто
Паттерн позволяющий менять поведение в зависимости от состояния.
Ярким примером является плеер. Если фильм играет, то контролы ведут себя одним образом, если на паузе другим, если проигрывание закончилось третьим. Основная идея в том, что если наша сущность может быть в нескольких состояниях(режим редактирования и просмотра, проигрывание и пауза, ограниченный режим и полный доступ и тп), то стоит обратить внимание на этот паттерн.
Средне
Паттерн позволяющий менять алгоритм динамически.
Определяем семейство алгоритмов(сортировки таблицы, способы логгирования, способы фильтрации) и динамически их меняем. Самое важное, что интерфейс реализации алгоритма не меняется, меняется только логика внутри. Была сортировка по убыванию, стало по возрастанию и тд.
Часто
Паттерн позволяющий определить структуру алгоритма, реализации давая возможность в подклассах реализовать детали.
Если у меня есть алгоритм, но в каждом подклассе меняется его реализация, то я использую шаблонный метод. Яркий пример абстрактный метод в в тайпскрипте. Используя его мы определяем интерфейс, но реализацию пишут подклассы.
Редко
Паттерн позволяющий внедрить объект в другие, который может выполнять операции над ними.
Если мне необходимо првоести схожие операции над большим количеством объектов коллекции или тп, то я реализую посетитель и он посещает все необходимы объекты(хорошо работает в связке с итератором) и выполняет операцию. Например переименование файлов, замена импортов, печать частей коллекции и тд, что-то однообразное, но в разных местах.
Редко
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent