Решают задачи эффективного и безопасного взаимодействия между объектами программы. ### Цепочка обязанностей Позволяет передавать запросы последовательно по цепочке обработчиков. Каждый последующий обработчик обрабатывает запрос и/или решает передавать ли запрос дальше по цепи. Например , есть некий метод, который принимает входные параметры. Необходимо сделать много разных проверок эти данных. <br> **Цитата из сайта** Как и многие другие поведенческие паттерны, Цепочка обязанностей базируется на том, чтобы превратить отдельные поведения в объекты. В нашем случае каждая проверка переедет в отдельный класс с единственным методом выполнения. Данные запроса, над которым происходит проверка, будут передаваться в метод как аргументы. А теперь по-настоящему важный этап. Паттерн предлагает связать объекты обработчиков в одну цепь. Каждый из них будет иметь ссылку на следующий обработчик в цепи. Таким образом, при получении запроса обработчик сможет не только сам что-то с ним сделать, но и передать обработку следующему объекту в цепочке. ##### Особенности - У всех поведенческих типов общий интерфейс - Для каждого случая можно конфигурировать свою цепочку обязанностей из одних и тех же поведенческих типов. [ссылка](https://refactoring.guru/ru/design-patterns/chain-of-responsibility) ### Команда Также известен как: Действие, Транзакция, Action, Command Превращает запросы в типы, что позволяет ставить запросы в очередь, легировать их, поддерживать отмену операций. Каждый вызов оборачивается в собственный класс с единственным методом, который и будет осуществлять вызов. Классы команд можно объединить под общим интерфейсом c единственным методом запуска. После этого одни и те же отправители смогут работать с различными командами, не привязываясь к их классам. [ссылка](https://refactoring.guru/ru/design-patterns/command) ### Итератор Также известен как: Iterator Позволяет вынести поведение обхода коллекции из самой коллекции в отдельный класс. Применимость - Когда нужно иметь несколько вариантов обхода одной и той же структуры данных. Текущий паттерн позволит не захламлять класс коллекции. - Когда хочется иметь единый интерфейс обхода структур данных. [ссылка](https://refactoring.guru/ru/design-patterns/iterator) ### Посредник Также известен как: Intermediary, Controller, Mediator позволяет уменьшить связанность множества классов между собой, благодаря перемещению этих связей в один класс-посредник. **Цитата из сайта** Паттерн Посредник заставляет объекты общаться не напрямую друг с другом, а через отдельный объект-посредник, который знает, кому нужно перенаправить тот или иной запрос. Благодаря этому, компоненты системы будут зависеть только от посредника, а не от десятков других компонентов. ##### Мой комментарий Как это работает: Группа экземпляров уведомляют один конкретный экземпляр-посредник о том, что они совершили какое-то действие. А дальше посредник уже решает, что делать дальше. Например, может вызвать какой-то метод у кого-либо из группы экземпляров [ссылка](https://refactoring.guru/ru/design-patterns/mediator) ### Снимок Также известен как: Хранитель, Memento Позволяет сохранять и восстанавливать прошлые состояния объектов **Цитата из сайта** Паттерн Снимок поручает создание копии состояния экземпляра самому экземпляру, который этим состоянием владеет. Паттерн предлагает держать копию состояния в специальном экземпляре-*снимке* с ограниченным интерфейсом, позволяющим, например, узнать дату изготовления или название снимка. Но, с другой стороны, снимок должен быть открыт для своего *создателя*, позволяя прочесть и восстановить его внутреннее состояние. [ссылка](https://refactoring.guru/ru/design-patterns/memento) ### Наблюдатель Также известен как: Издатель-Подписчик, Слушатель, Observer создаёт механизм подписки, позволяющий одним объектам следить и реагировать на события, происходящие в других объектах. **Цитата из сайта** Давайте называть <u>Издателями</u> те экземпляры, которые содержат важное или интересное для других состояние. Остальные экземпляры, которые хотят отслеживать изменения этого состояния, назовём <u>Подписчиками</u>. Паттерн Наблюдатель предлагает хранить внутри экземпляра издателя список ссылок на экземпляры подписчиков, причём издатель не должен вести список подписки самостоятельно. Он предоставит методы, с помощью которых подписчики могли бы добавлять или убирать себя из списка. [ссылка](https://refactoring.guru/ru/design-patterns/observer) ### Состояние Также известен как: State позволяет объектам менять поведение в зависимости от своего состояния. Извне создаётся впечатление, что изменился класс объекта. **Цитата из сайта** Паттерн Состояние предлагает создать отдельные классы для каждого состояния, в котором может пребывать объект, а затем вынести туда поведения, соответствующие этим состояниям. Вместо того, чтобы хранить исходный код всех состояний, первоначальный объект, называемый *контекстом*, будет содержать ссылку на один из объектов-состояний и делегировать ему работу, зависящую от состояния. Благодаря тому, что объекты состояний будут иметь общий интерфейс, контекст сможет делегировать работу состоянию, не привязываясь к его классу. Поведение контекста можно будет изменить в любой момент, подключив к нему другой объект-состояние. [ссылка](https://refactoring.guru/ru/design-patterns/state) ### Стратегия Также известен как: Strategy Определяет семейство схожих алгоритмов и помещает каждый из них в собственный класс, после чего алгоритмы можно взаимозаменять прямо во время исполнения программы. **Цитата из сайта** Паттерн Стратегия предлагает определить семейство схожих алгоритмов, которые часто изменяются или расширяются, и вынести их в собственные классы, называемые *стратегиями*. Вместо того, чтобы изначальный класс сам выполнял тот или иной алгоритм, он будет играть роль контекста, ссылаясь на одну из стратегий и делегируя ей выполнение работы. Чтобы сменить алгоритм, вам будет достаточно подставить в контекст другой объект-стратегию. Важно, чтобы все стратегии имели общий интерфейс. Используя этот интерфейс, контекст будет независимым от конкретных классов стратегий. С другой стороны, вы сможете изменять и добавлять новые виды алгоритмов, не трогая код контекста. [ссылка](https://refactoring.guru/ru/design-patterns/strategy) ### Шаблонный метод определяет скелет алгоритма, перекладывая ответственность за некоторые его шаги на подклассы. Паттерн позволяет подклассам переопределять шаги алгоритма, не меняя его общей структуры. **Цитата из сайта** Паттерн Шаблонный метод предлагает разбить алгоритм на последовательность шагов, описать эти шаги в отдельных методах и вызывать их в одном шаблонном методе друг за другом. Это позволит подклассам переопределять некоторые шаги алгоритма, оставляя без изменений его структуру и остальные шаги, которые для этого подкласса не так важны. **Особенности** - Рекомендуется сделать шаблонный метод финальным, чтобы подклассы не могли переопределить его. - Можно использовать «хуки» ( как я понимаю речь о возможности внедрения уникальных шагов в алгоритме, которых нет в родительском классе) - 4 минуса и только одно преимущество [Ссылка](https://refactoring.guru/ru/design-patterns/template-method) ### Посетитель Также известен как: Visitor Позволяет добавлять в программу новые операции, не изменяя классы объектов, над которыми эти операции могут выполняться. **Цитата из сайта** Паттерн Посетитель предлагает разместить новое поведение в отдельном классе, вместо того чтобы множить его сразу в нескольких классах. Объекты, с которыми должно было быть связано поведение, не будут выполнять его самостоятельно. Вместо этого вы будете передавать эти объекты в методы посетителя. ##### Мой комментарий Допустим, у нас есть 10 классов, которые между собой мало чем связаны и решают абсолютно разные задачи. Однако, тебе нужно выполнить какие-то операции со всеми этими 10 классами. Ты создаешь во всех этих 10 классах один общий метод (accept), который принимает класс Visitor и вызывает уникальный метод из Visitor, созданный для каждого из 10 классов. В этих уникальных методах ты и реализуешь алгоритм, который «находит подход» к каждому из 10 классов и выполняет необходимые операции с каждым из них. Например, если тебе нужно сделать экспорт неких данных, то на выходе у тебя получится один json-файл с информацией из 10 разных классов. И при этом тебе не не пришлось изменять эти 10 классов. [ссылка](https://refactoring.guru/ru/design-patterns/visitor)