Поведенческие паттерны: О поведенческих шаблонах проектирования простым языком

Содержание

Поведенческие паттерны проектирования

Весенняя скидка

Цепочка обязанностей Chain of Responsibility
Позволяет передавать запросы последовательно по цепочке обработчиков. Каждый последующий обработчик решает, может ли он обработать запрос сам и стоит ли передавать запрос дальше по цепи.
Команда Command
Превращает запросы в объекты, позволяя передавать их как аргументы при вызове методов, ставить запросы в очередь, логировать их, а также поддерживать отмену операций.

Итератор Iterator
Даёт возможность последовательно обходить элементы составных объектов, не раскрывая их внутреннего представления.
Посредник Mediator
Позволяет уменьшить связанность множества классов между собой, благодаря перемещению этих связей в один класс-посредник.
Снимок Memento
Позволяет сохранять и восстанавливать прошлые состояния объектов, не раскрывая подробностей их реализации.
Наблюдатель Observer
Создаёт механизм подписки, позволяющий одним объектам следить и реагировать на события, происходящие в других объектах.
Состояние State
Позволяет объектам менять поведение в зависимости от своего состояния.
Извне создаётся впечатление, что изменился класс объекта.
Стратегия Strategy
Определяет семейство схожих алгоритмов и помещает каждый из них в собственный класс, после чего алгоритмы можно взаимозаменять прямо во время исполнения программы.
Шаблонный метод Template Method
Определяет скелет алгоритма, перекладывая ответственность за некоторые его шаги на подклассы. Паттерн позволяет подклассам переопределять шаги алгоритма, не меняя его общей структуры.
Посетитель Visitor
Позволяет добавлять в программу новые операции, не изменяя классы объектов, над которыми эти операции могут выполняться.

Войти
В трех частях статьи мы последовательно рассмотрим 23 шаблона проектирования, которые впервые были перечислены в книге «Шаблоны проектирования: элементы объектно-ориентированного программного обеспечения». Описание каждого шаблона включает структуру, объяснение, рекомендации по использованию и пример практического применения. Первая часть посвящена поведенческим шаблонам, вторая – структурным, а третья – порождающим.
Шаблон «Цепочка обязанностей»
Все обработчики реализуют один абстрактный класс Handler, который содержит ссылку на самого себя (successor) для делегирования обязанностей по обработке следующему обработчику в цепочке. Реализация метода handleRequest() по умолчанию выполняет такую делегацию.
Пример
Этот шаблон используется в некоторых языках для обработки исключений. Когда в методе возникает исключение, среда выполнения проверяет, есть ли в методе механизм для обработки исключения или его следует передать в стек вызовов.

При передаче в стек вызовов процесс повторяется до тех пор, пока не будет найден код для обработки исключения или пока не останется родительских объектов, которым можно передать запрос.
Больше полезных материалов вы найдете на нашем телеграм-канале «Библиотека программиста»
Интересно, перейти к каналу
Поведенческий шаблон «Команда»
Назначение
Преобразует запросы в объекты, позволяя передавать их как аргументы при вызове методов, ставить запросы в очередь, сохранять историю, а также поддерживать отмену операций.
Когда использовать
Если нужна функциональность обратного вызова.
Запросы должны обрабатываться в разное время или в разном порядке.
Необходимо сохранять историю запросов.
Если вызывающая сторона должна быть отделена от объекта, обрабатывающего вызов.

Структура
Шаблон «Команда»
Клиент (Client) создает объекты конкретных команд. Отправитель (Invoker) хранит ссылку на объект команды и обращается к нему, если нужно выполнить какое-то действие. Отправитель работает с командами только через их общий интерфейс.
Команда (Command) описывает общий для всех конкретных команд (Concrete Command) интерфейс. Отправитель не знает, какую конкретно команду использует, так как получает готовый объект команды от клиента. Получатель (Receiver) содержит бизнес-логику программы.
Пример
Очереди заданий широко используются для облегчения асинхронной обработки алгоритмов. При использовании шаблона команды можно передать очереди заданий для обработки некую функцию таким образом, чтобы очередь не знала о фактическом результате ее выполнения.
Объект команды, который ставится в очередь, реализует свой конкретный алгоритм в рамках интерфейса, ожидаемого очередью.
Поведенческий шаблон «Интерпретатор»
Назначение
Определяет представление для грамматики, а также механизм для понимания и действий с грамматикой.
Когда использовать
Есть грамматика, которую нужно интерпретировать и которая может быть представлена в виде больших синтаксических деревьев.
Грамматика проста.
Эффективность не важна.
Желательно отделить грамматику от основных выражений.
Структура
Шаблон «Интерпретатор»
Абстрактное выражение (Abstract Expression) объявляет метод Interpret(). Для каждого символа грамматики создается свой объект Terminal Expression (терминальное выражение). Для каждого отдельного правила грамматики создается свой объект Nonterminal Expression (нетерминальное выражение)
Контекст (Context) содержит общую информацию, может использоваться для сохранения состояния операций и последующего доступа к сохраненному состоянию. Клиент (Client) строит предложения с данной грамматикой в виде абстрактного синтаксического дерева, узлами которого являются объекты
Terminal Expression и Nonterminal Expression.
Пример
Игры с текстовыми командами, популярные в 1980-х годах. Во многих из них были простые команды, например, «шаг вниз» , которые позволяли перемещаться по игре. Эти команды могли быть вложены друг в друга так, чтобы можно было изменить их значение. Например, результат выполнения go in «войти» отличался от go up «подняться». Создавая иерархию команд на основе команды и классификатора (нетерминальных и терминальных выражений), приложение могло легко соотнести множество вариантов команд с нужными действиями.
Поведенческий шаблон «Итератор»
Назначение
Позволяет получить доступ к элементам составного объекта без доступа к его внутреннему представлению.
Когда использовать
Требуется доступ к элементам без открытия доступа ко всему представлению.
Необходимы множественные или параллельные обходы элементов.
Нужен единый интерфейс для обхода.
Существуют небольшие различия между деталями реализации различных итераторов.
Структура
Шаблон «Итератор»
Итератор (Iterator) описывает интерфейс для доступа и обхода элементов коллекции. Конкретный итератор (Concrete Iterator) реализует алгоритм обхода какой-то конкретной коллекции.
Коллекция (Aggregate) описывает интерфейс получения итератора из коллекции. Конкретная коллекция (Concrete Aggregate) возвращает новый экземпляр определенного конкретного итератора, связав его с текущим объектом коллекции. Клиент работает со всеми объектами через интерфейсы коллекции и итератора.
Пример
Реализация шаблона итератора в Java позволяет пользователям обращаться к различным типам наборов данных, не беспокоясь о внутренней реализации коллекции. Поскольку клиенты просто взаимодействуют с интерфейсом итератора, коллекциям остается определить подходящий итератор самостоятельно. Некоторые из них предоставляют полный доступ к базовому набору данных, в то время как другие могут ограничивать определенные функции, например, удаление элементов.
Поведенческий шаблон «Посредник»
Назначение
Обеспечивает слабое зацепление, инкапсулируя способ взаимодействия и связи между разрозненными наборами объектов. Позволяет действиям каждого набора объектов изменяться независимо друг от друга.
Когда использовать
Связь между наборами объектов хорошо определена и сложна.
Существует слишком много взаимосвязей, и необходима общая точка управления или связи.
Структура
Шаблон «Посредник’
Посредник (Mediator) определяет интерфейс для обмена информацией с объектами Коллеги (Colleague). Конкретный посредник координирует действия объектов Коллеги. Каждый класс Коллеги знает о своем объекте Посредник, все Коллеги обмениваются информацией только с Посредником, не напрямую.
Пример
Приложение для управления почтовой рассылкой отслеживает, кто и на какие новости подписан, и предоставляет единую точку доступа, через которую администратор рассылки может отправлять сообщения всем или отдельными подписчиками.
Поведенческий шаблон «Хранитель»
Назначение
Позволяет захватывать и извлекать внутреннее состояние объекта, чтобы его можно было восстановить позже, не нарушая инкапсуляции.
Когда использовать
Если внутреннее состояние объекта должно быть сохранено и восстановлено позднее.
Внутреннее состояние не может быть раскрыто интерфейсами без раскрытия реализации.
Границы инкапсуляции должны быть сохранены.
Структура
Шаблон «Хранитель»
Создатель (Originator) делает снимки своего состояния и может воспроизводить прошлое состояние, если передать в него готовый снимок. Хранитель (Memento) — простой объект данных, содержащий состояние создателя. Опекун (Caretaker) знает, когда делать снимок создателя и когда его нужно восстанавливать.
Пример
С помощью «Хранителя» можно реализовать функцию отмены действия. Сериализуя и десериализуя состояние объекта до того, как произойдет изменение, можно сохранить снимок для последующего восстановления, если пользователь решит отменить операцию.
Поведенческий шаблон «Наблюдатель»
Назначение
Позволяет одному или нескольким объектам получать уведомления об изменениях состояния других объектов в системе.
Когда использовать
Если изменение состояния одного или нескольких объектов должно вызывать реакцию других объектов.
Нужно управлять массовой рассылкой.
Подписчики не платят за получение уведомлений.
Структура
Шаблон «Наблюдатель»
Наблюдатель (Observer) передает запрос одновременно всем заинтересованным получателям (Concrete Subject), но позволяет им динамически подписываться или отписываться от таких оповещений.
Пример
Этот шаблон используется почти в каждом графическом интерфейсе. Когда пользователь вызывает событие, например, нажатие кнопки, элемент управления перебирает все зарегистрированные наблюдатели и посылает каждому из них уведомление.
Поведенческий шаблон «Состояние»
Назначение
Связывает обстоятельства объекта с его поведением, позволяя объекту вести себя по-разному в зависимости от его внутреннего состояния.
Когда использовать
Если поведение объекта должно зависеть от его состояния.
Поведение объекта с его состоянием связывают сложные условия.
Переходы между состояниями должны быть явными.
Структура
Шаблон «Состояние»
Контекст (Context) хранит ссылку на объект состояния и передает ему часть работы, зависящей от состояний. Состояние (State) описывает общий интерфейс для всех конкретных состояний. Конкретные состояния (Concrete State) реализуют поведения, связанные с определенным состоянием контекста.
Пример
Электронное письмо может иметь различные состояния, каждое из которых влияет на то, как объект обрабатывает различные функции. Если состояние «не отправлено», то вызов send() отправит сообщение, а вызов recallMessage() либо выдаст ошибку, либо ничего не сделает. Однако если состояние «отправлено», то вызов send() либо выдаст ошибку, либо ничего не сделает, а вызов recallMessage() попытается отправить уведомление получателям. Чтобы избежать условных выражений в большинстве или во всех методах, существует несколько объектов состояния, которые обрабатывают реализацию в соответствии со своим конкретным состоянием. Вызовы внутри объекта Email будут передаваться соответствующему объекту состояния для обработки.
Поведенческий шаблон «Стратегия»
Назначение
Определяет семейство схожих алгоритмов и помещает каждый из них в собственный класс, благодаря чему алгоритмы можно взаимозаменять во время исполнения программы.
Когда использовать
Если единственное различие между многочисленными родственными классами заключается в их поведении.
Требуется несколько версий или вариаций алгоритма.
Алгоритмы получают доступ или используют данные, которые не должны быть доступны вызывающему коду.
Поведение класса должно определяться во время выполнения.
Условные операторы сложны и их трудно поддерживать.
Структура
Шаблон «Стратегия»
Контекст (Context) хранит ссылку на объект конкретной стратегии и работает с ним через общий интерфейс стратегий. Стратегия (Strategy) определяет интерфейс, общий для всех вариаций алгоритма. Конкретные стратегии (Concrete Strategy) реализуют различные вариации алгоритма.
Пример
При импорте данных в новую систему на основе набора данных могут выполняться различные алгоритмы проверки. Настроив импорт на использование стратегий, можно убрать условную логику, определяющую, какой набор проверки запускать, и отделить импорт от кода проверки. Это позволит динамически вызывать одну или несколько стратегий во время импорта.
Поведенческий шаблон «Шаблонный метод»
Назначение
Определяет структуру алгоритма, позволяя реализующим классам определять фактическое поведение.
Когда использовать
Если необходима единая абстрактная реализация алгоритма.
Общее поведение среди подклассов должно быть локализовано в общем классе.
Родительские классы должны иметь возможность единообразно вызывать поведение в своих подклассах.
Большинство или все подклассы должны реализовать поведение.
Структура
Шаблон «Шаблонный метод»
Абстрактный класс (Abstract Class) определяет шаги алгоритма и содержит шаблонный метод, состоящий из вызовов этих шагов. Конкретный класс (Concrete Class) переопределяет некоторые (или все) шаги алгоритма. Конкретные классы не переопределяют сам шаблонный метод.
Пример
Родительский класс InstantMessage будет включать все методы, необходимые для обработки отправки сообщения. Однако фактическая сериализация данных для отправки может отличаться в зависимости от реализации. Видеосообщение и обычное текстовое сообщение потребуют различных алгоритмов для правильной сериализации данных. Подклассы InstantMessage могут предоставить свою собственную реализацию метода сериализации, позволяя родительскому классу работать с ними без понимания деталей их реализации.
Поведенческий шаблон «Посетитель»
Назначение
Позволяет применять одну или несколько операций к набору объектов во время выполнения, отделяя операции от структуры объекта.
Когда использовать
Если над структурой объекта выполняется множество несвязанных операций.
Структура объекта не должна меняться, но операции, выполняемые над ней, могут.
Операции должны выполняться над конкретными классами структуры объекта.
Раскрытие внутреннего состояния или операций структуры объекта допустимо.
Операции должны быть способны работать с несколькими структурами, реализующими одни и те же интерфейсные наборы.
Структура
Шаблон «Посетитель»
Посетитель (Visitor) описывает общий интерфейс для всех типов посетителей. Он объявляет набор методов, отличающихся типом входящего параметра, которые нужны для запуска операции для всех типов конкретных элементов.
Конкретные посетители (Concrete Visitor) реализуют какое-то особенное поведение для всех типов элементов. Элемент (Element) описывает метод принятия посетителя. Конкретные элементы (Concrete Element)реализуют методы принятия посетителя. Клиентом (Client) обычно является коллекция или сложный составной объект.
Пример
Расчет налогов в разных системах налогообложения по наборам счетов-фактур потребует множества различных вариантов логики расчета. Реализация шаблона «Посетитель» позволяет отделить логику от счетов-фактур. Это позволяет «посетить» иерархию элементов с помощью кода вычисления, который затем может применить соответствующие налоговые ставки. Сменить систему налогообложения в этом случае просто, достаточно сменить «Посетителя».
***
Материалы по теме
Шаблоны проектирования по-человечески: поведенческие паттерны в примерах
Шаблоны проектирования в JavaScript простыми словами
Шаблоны проектирования по-человечески: 6 порождающих паттернов, которые упростят жизнь
Стратегия

Намерение
Стратегия — это поведенческий шаблон проектирования, который позволяет определить семейство алгоритмов, поместить каждый из них в отдельный класс и сделать их объекты взаимозаменяемыми.
Проблема
Однажды вы решили создать навигационное приложение для случайных путешественников. В основе приложения лежала красивая карта, которая помогала пользователям быстро ориентироваться в любом городе.
Одной из наиболее востребованных функций приложения было автоматическое планирование маршрута. Пользователь должен иметь возможность ввести адрес и увидеть на карте самый быстрый маршрут к этому пункту назначения.
Первая версия приложения могла строить маршруты только по дорогам. Люди, которые путешествовали на машине, распирали от радости. Но, видимо, не всем нравится водить машину в отпуске. Итак, в следующем обновлении вы добавили возможность строить пешеходные маршруты. Сразу после этого вы добавили еще одну опцию, позволяющую людям пользоваться общественным транспортом на своих маршрутах.
Однако это было только начало. Позже вы планировали добавить построение маршрута для велосипедистов. А еще позже — еще один вариант построения маршрутов по всем достопримечательностям города.
Код навигатора раздулся.
Хотя с точки зрения бизнеса приложение было успешным, техническая часть вызвала у вас много головной боли. Каждый раз, когда вы добавляли новый алгоритм маршрутизации, основной класс навигатора увеличивался вдвое. В какой-то момент зверя стало слишком сложно поддерживать.
Любое изменение в одном из алгоритмов, будь то простое исправление ошибки или небольшая корректировка уличного счета, влияло на весь класс, увеличивая вероятность создания ошибки в уже работающем коде.
Кроме того, командная работа стала неэффективной. Ваши товарищи по команде, которых наняли сразу после успешного релиза, жалуются, что тратят слишком много времени на разрешение конфликтов слияния. Реализация новой функции требует от вас изменения того же самого огромного класса, конфликтующего с кодом, созданным другими людьми.
Решение
Шаблон Стратегия предполагает, что вы берете класс, который делает что-то конкретное множеством различных способов, и выделяете все эти алгоритмы в отдельные классы, называемые стратегиями .
Исходный класс с именем context должен иметь поле для хранения ссылки на одну из стратегий. Контекст делегирует работу связанному объекту стратегии вместо того, чтобы выполнять его самостоятельно.
Контекст не отвечает за выбор подходящего алгоритма для задания. Вместо этого клиент передает желаемую стратегию контексту. На самом деле контекст мало что знает о стратегиях. Он работает со всеми стратегиями через один и тот же общий интерфейс, который предоставляет только один метод запуска алгоритма, инкапсулированного в выбранной стратегии.
Таким образом, контекст становится независимым от конкретных стратегий, поэтому вы можете добавлять новые алгоритмы или модифицировать существующие без изменения кода контекста или других стратегий.
Стратегии планирования маршрута.
В нашем навигационном приложении каждый алгоритм маршрутизации можно выделить в отдельный класс с помощью одного метода buildRoute . Метод принимает исходную и конечную точки и возвращает набор контрольных точек маршрута.
Несмотря на то, что при одних и тех же аргументах каждый класс маршрутизации может построить свой маршрут, основному классу навигатора все равно, какой алгоритм выбран, поскольку его основной задачей является отображение набора контрольных точек на карте. У класса есть метод для переключения активной стратегии маршрутизации, поэтому его клиенты, такие как кнопки в пользовательском интерфейсе, могут заменить текущее выбранное поведение маршрутизации другим.
Аналогия из реального мира
Различные способы добраться до аэропорта.
Представьте, что вам нужно добраться до аэропорта. Вы можете сесть на автобус, заказать такси или сесть на велосипед. Это ваши транспортные стратегии. Вы можете выбрать одну из стратегий в зависимости от таких факторов, как бюджет или временные ограничения.
Структура
Контекст поддерживает ссылку на одну из конкретных стратегий и взаимодействует с этим объектом только через интерфейс стратегии.
Интерфейс Strategy является общим для всех конкретных стратегий. Он объявляет метод, который контекст использует для выполнения стратегии.
Конкретные стратегии реализуют различные варианты алгоритма, используемого контекстом.
Контекст вызывает метод выполнения для связанного объекта стратегии каждый раз, когда ему необходимо запустить алгоритм. Контекст не знает, с какой стратегией он работает или как выполняется алгоритм.
Клиент создает определенный объект стратегии и передает его контексту. Контекст предоставляет установщик, который позволяет клиентам заменить стратегию, связанную с контекстом, во время выполнения.
Псевдокод
В этом примере контекст использует несколько стратегий для выполнения различных арифметических операций.
// В интерфейсе стратегии объявлены общие для всех операции // поддерживаемые версии некоторого алгоритма. Контекст использует это // интерфейс для вызова алгоритма, определенного конкретным // стратегии. Интерфейс Стратегия метод выполнить (а, б) // Конкретные стратегии реализуют алгоритм при следовании // интерфейс базовой стратегии. Интерфейс делает их // взаимозаменяемы в контексте. класс ConcreteStrategyAdd реализует стратегию метод execute(a, b) есть вернуть а + б класс ConcreteStrategySubtract реализует стратегию метод execute(a, b) есть вернуть а - б класс ConcreteStrategyMultiply реализует стратегию метод execute(a, b) есть вернуть а * б // Контекст определяет интересующий клиентов интерфейс. Контекст класса // Контекст поддерживает ссылку на одну из стратегий // объекты. Контекст не знает конкретного класса // стратегия. Он должен работать со всеми стратегиями через // интерфейс стратегии. частная стратегия: Стратегия // Обычно контекст принимает стратегию через // конструктор, а также предоставляет сеттер, чтобы // стратегию можно переключать во время выполнения. метод setStrategy (Стратегия стратегии) this.strategy = стратегия // Контекст делегирует часть работы объекту стратегии // вместо реализации нескольких версий // алгоритм сам по себе. метод executeStrategy(int a, int b) возврат Strategy.execute(a, b) // Клиентский код выбирает конкретную стратегию и передает ее в // контекст. Клиент должен знать об отличиях // между стратегиями, чтобы сделать правильный выбор. класс ExampleApplication метод main() есть Создать объект контекста. Прочитайте первое число. Прочтите последнюю цифру. Прочитайте желаемое действие из пользовательского ввода. если (действие == сложение), то context.setStrategy(новый ConcreteStrategyAdd()) если (действие == вычитание), то context.setStrategy (новый ConcreteStrategySubtract()) если (действие == умножение), то context.setStrategy (новый ConcreteStrategyMultiply()) результат = context. executeStrategy (первое число, второе число) Распечатать результат.
Применимость

Шаблон Strategy позволяет изолировать код, внутренние данные и зависимости различных алгоритмов от остального кода. Различные клиенты получают простой интерфейс для выполнения алгоритмов и переключения их во время выполнения.
Шаблон Стратегия позволяет отказаться от такого условного выражения, выделяя все алгоритмы в отдельные классы, реализующие один и тот же интерфейс. Исходный объект делегирует выполнение одному из этих объектов вместо реализации всех вариантов алгоритма.
Как реализовать
В классе контекста определите алгоритм, который подвержен частым изменениям. Это также может быть массивное условное выражение, которое выбирает и выполняет вариант одного и того же алгоритма во время выполнения.
Объявить интерфейс стратегии общим для всех вариантов алгоритма.
Один за другим извлеките все алгоритмы в их собственные классы. Все они должны реализовать интерфейс стратегии.
В классе контекста добавить поле для хранения ссылки на объект стратегии. Предоставьте сеттер для замены значений этого поля. Контекст должен работать с объектом стратегии только через интерфейс стратегии. Контекст может определять интерфейс, который позволяет стратегии получать доступ к своим данным.
Клиенты контекста должны связать его с подходящей стратегией, которая соответствует тому, как они ожидают, что контекст будет выполнять свою основную работу.
Плюсы и минусы

Многие современные языки программирования поддерживают функциональные типы, что позволяет реализовывать различные версии алгоритма внутри набора анонимных функций. Затем вы могли бы использовать эти функции точно так же, как вы использовали бы объекты стратегии, но без раздувания кода дополнительными классами и интерфейсами.
Связь с другими шаблонами
Мост, Состояние, Стратегия (и в некоторой степени Адаптер) имеют очень похожую структуру. Действительно, все эти шаблоны основаны на композиции, которая делегирует работу другим объектам. Однако все они решают разные задачи. Шаблон — это не просто рецепт структурирования вашего кода определенным образом. Он также может сообщить другим разработчикам о проблеме, которую решает шаблон.
Command и Strategy могут выглядеть одинаково, потому что вы можете использовать их для параметризации объекта с помощью некоторого действия. Однако у них очень разные намерения.
Вы можете использовать команду для преобразования любой операции в объект. Параметры операции становятся полями этого объекта. Преобразование позволяет отложить выполнение операции, поставить ее в очередь, сохранить историю команд, отправить команды в удаленные службы и т. д.
С другой стороны, Стратегия обычно описывает разные способы выполнения одних и тех же действий, позволяя вам менять местами эти алгоритмы в одном классе контекста.
Decorator позволяет изменить внешний вид объекта, а Strategy позволяет изменить его внутреннюю часть.
Шаблонный метод
основан на наследовании: он позволяет вам изменять части алгоритма, расширяя эти части в подклассах. Стратегия основана на композиции: вы можете изменять части поведения объекта, снабжая его различными стратегиями, соответствующими этому поведению. Метод шаблона работает на уровне класса, поэтому он статичен. Стратегия работает на уровне объекта, позволяя переключать поведение во время выполнения.
Состояние можно рассматривать как расширение Стратегии. Оба шаблона основаны на композиции: они изменяют поведение контекста, делегируя часть работы вспомогательным объектам. Стратегия делает эти объекты полностью независимыми и не знающими друг друга. Однако State не ограничивает зависимости между конкретными состояниями, позволяя им изменять состояние контекста по желанию.
Примеры кодов
Цепочка ответственности

Намерение
Цепочка ответственности — это поведенческий шаблон проектирования, позволяющий передавать запросы по цепочке обработчиков. Получив запрос, каждый обработчик решает либо обработать запрос, либо передать его следующему обработчику в цепочке.
Проблема
Представьте, что вы работаете над системой онлайн-заказов. Вы хотите ограничить доступ к системе, чтобы только авторизованные пользователи могли создавать заказы. Кроме того, пользователи с правами администратора должны иметь полный доступ ко всем заказам.
После небольшого планирования вы поняли, что эти проверки должны выполняться последовательно. Приложение может попытаться аутентифицировать пользователя в системе всякий раз, когда оно получает запрос, содержащий учетные данные пользователя. Однако, если эти учетные данные неверны и аутентификация не удалась, нет причин продолжать какие-либо другие проверки.
Запрос должен пройти ряд проверок, прежде чем система заказов сможет его обработать.
В течение следующих нескольких месяцев вы реализовали еще несколько таких последовательных проверок.
Один из ваших коллег предположил, что передавать необработанные данные прямо в систему заказов небезопасно. Итак, вы добавили дополнительный шаг проверки для очистки данных в запросе.
Позже кто-то заметил, что система уязвима для взлома паролей методом грубой силы. Чтобы предотвратить это, вы быстро добавили проверку, которая отфильтровывает повторяющиеся неудачные запросы, поступающие с одного и того же IP-адреса.
Кто-то еще предложил ускорить работу системы, возвращая кэшированные результаты при повторных запросах, содержащих одни и те же данные. Следовательно, вы добавили еще одну проверку, которая пропускает запрос в систему, только если нет подходящего кэшированного ответа.
Чем больше код рос, тем запутаннее он становился.
Код чеков, и без того выглядевший кашей, становился все более и более раздутым по мере добавления каждой новой функции. Изменение одного чека иногда влияло на другие. Хуже всего то, что когда вы пытались повторно использовать проверки для защиты других компонентов системы, вам приходилось дублировать часть кода, поскольку эти компоненты требовали некоторых проверок, но не всех.
Система стала очень сложной для понимания и дорогой в обслуживании. Вы какое-то время боролись с кодом, пока однажды не решили провести рефакторинг всего этого.
Решение
Как и многие другие поведенческие шаблоны проектирования, цепочка ответственности полагается на преобразование определенных поведений в автономные объекты, называемые обработчиками . В нашем случае каждая проверка должна быть извлечена в свой класс с помощью одного метода, выполняющего проверку. Запрос вместе со своими данными передается этому методу в качестве аргумента.
Шаблон предлагает связать эти обработчики в цепочку. Каждый связанный обработчик имеет поле для хранения ссылки на следующий обработчик в цепочке. Помимо обработки запроса, обработчики передают запрос дальше по цепочке. Запрос перемещается по цепочке до тех пор, пока все обработчики не получат возможность его обработать.
Вот лучшая часть: обработчик может принять решение не передавать запрос дальше по цепочке и эффективно остановить дальнейшую обработку.
В нашем примере с системами заказов обработчик выполняет обработку, а затем решает, передать ли запрос дальше по цепочке. Предполагая, что запрос содержит правильные данные, все обработчики могут выполнять свое основное поведение, будь то проверка подлинности или кэширование.
Дрессировщики выстраиваются один за другим, образуя цепочку.
Однако есть немного другой подход (и он немного более каноничный), при котором, получив запрос, обработчик решает, может ли он его обработать. Если это возможно, он не передает запрос дальше. Таким образом, либо только один обработчик обрабатывает запрос, либо вообще ничего. Этот подход очень распространен при работе с событиями в стеках элементов в графическом пользовательском интерфейсе.
Например, когда пользователь нажимает кнопку, событие распространяется по цепочке элементов графического интерфейса, которая начинается с кнопки, проходит по ее контейнерам (таким как формы или панели) и заканчивается главным окном приложения. Событие обрабатывается первым элементом в цепочке, способным его обработать. Этот пример также примечателен тем, что он показывает, что цепочку всегда можно извлечь из дерева объектов.
Цепочка может быть сформирована из ветви дерева объектов.
Крайне важно, чтобы все классы обработчиков реализовывали один и тот же интерфейс. Каждый конкретный обработчик должен заботиться только о следующем, имеющем метод execute . Таким образом, вы можете создавать цепочки во время выполнения, используя различные обработчики, не связывая свой код с их конкретными классами.
Аналогия из реального мира
Звонок в службу технической поддержки может проходить через нескольких операторов.
Вы только что купили и установили на свой компьютер новое оборудование. Поскольку вы гик, на компьютере установлено несколько операционных систем. Вы пытаетесь загрузить их все, чтобы увидеть, поддерживается ли оборудование. Windows автоматически обнаруживает и включает оборудование. Однако ваш любимый линукс отказывается работать с новым железом. С небольшим проблеском надежды вы решаете позвонить по телефону техподдержки, указанному на коробке.
Первое, что вы слышите, это механический голос автоответчика. Он предлагает девять популярных решений различных проблем, ни одно из которых не имеет отношения к вашему делу. Через некоторое время робот подключает вас к живому оператору.
Увы, ничего конкретного оператор подсказать тоже не может. Он продолжает цитировать длинные выдержки из руководства, отказываясь слушать ваши комментарии. Услышав фразу «вы пробовали выключить и снова включить компьютер?» в 10-й раз вы требуете, чтобы вас соединили с настоящим инженером.
В конце концов, оператор передает ваш звонок одному из инженеров, который, вероятно, часами жаждал живого человеческого общения, сидя в своей одинокой серверной в темном подвале какого-то офисного здания. Инженер расскажет вам, где скачать подходящие драйверы для вашего нового оборудования и как установить их в Linux. Наконец-то решение! Вы заканчиваете разговор, разрываясь от радости.
Структура
Обработчик объявляет интерфейс, общий для всех конкретных обработчиков. Обычно он содержит только один метод для обработки запросов, но иногда может иметь и другой метод для установки следующего обработчика в цепочке.
Базовый обработчик — это необязательный класс, в который можно поместить шаблонный код, общий для всех классов обработчиков.
Обычно этот класс определяет поле для хранения ссылки на следующий обработчик. Клиенты могут построить цепочку, передав обработчик конструктору или сеттеру предыдущего обработчика. Класс также может реализовать поведение обработки по умолчанию: он может передать выполнение следующему обработчику после проверки его существования.
Бетонные обработчики содержат фактический код для обработки запросов. При получении запроса каждый обработчик должен решить, обрабатывать ли его и, дополнительно, передавать ли по цепочке.
Обработчики обычно автономны и неизменяемы, принимая все необходимые данные только один раз через конструктор.
Клиент может составлять цепочки только один раз или составлять их динамически, в зависимости от логики приложения. Обратите внимание, что запрос может быть отправлен любому обработчику в цепочке — он не обязательно должен быть первым.
Псевдокод
В этом примере шаблон Цепочка ответственности отвечает за отображение контекстной справочной информации для активных элементов графического интерфейса.
Классы GUI построены по шаблону Composite. Каждый элемент связан со своим элементом-контейнером. В любой момент вы можете построить цепочку элементов, которая начинается с самого элемента и проходит через все его элементы-контейнеры.
Графический интерфейс приложения обычно имеет структуру дерева объектов. Например, Класс Dialog , который отображает главное окно приложения, будет корнем дерева объектов. Диалог содержит панелей , которые могут содержать другие панели или простые низкоуровневые элементы, такие как кнопок и текстовых полей .
Простой компонент может отображать краткие контекстные всплывающие подсказки, если компоненту назначен текст справки. Но более сложные компоненты определяют свой собственный способ отображения контекстной справки, например, показ выдержки из руководства или открытие страницы в браузере.
Вот как запрос на помощь проходит через объекты GUI.
Когда пользователь наводит курсор мыши на элемент и нажимает клавишу F1 , приложение обнаруживает компонент под указателем и отправляет ему запрос на помощь. Запрос проходит через все контейнеры элемента, пока не достигнет элемента, способного отображать справочную информацию.
// Интерфейс обработчика объявляет метод для выполнения // запрос. Интерфейс ComponentWithContextualHelp метод showHelp() // Базовый класс для простых компонентов. абстрактный класс Компонент реализует ComponentWithContextualHelp поле tooltipText: строка // Контейнер компонента действует как следующая ссылка в // цепочка обработчиков. Контейнер защищенного поля: Контейнер // Компонент показывает всплывающую подсказку, если есть текст справки // присвоено ему. В противном случае вызов перенаправляется на // контейнер, если он существует. метод showHelp() есть если (текст подсказки != ноль) // Показать всплывающую подсказку. еще контейнер.showHelp() // Контейнеры могут содержать как простые компоненты, так и другие // контейнеры как дочерние элементы. Цепные отношения // установлено здесь. Класс наследует поведение showHelp от // его родитель. абстрактный класс Контейнер расширяет компонент дочерние элементы защищенного поля: массив компонентов метод add(child) есть дети.добавить(ребенок) ребенок.контейнер = это // Примитивные компоненты могут работать со справкой по умолчанию // выполнение... Класс Кнопка расширяет Компонент // ... // Но сложные компоненты могут переопределить значение по умолчанию // выполнение. Если текст справки не может быть предоставлен в новом // таким образом, компонент всегда может вызвать базовую реализацию // (см. Класс компонента). класс Panel расширяет контейнер поле modalHelpText: строка метод showHelp() есть если (modalHelpText != ноль) // Показать модальное окно с текстом справки. еще супер.showHelp() // ...то же, что и выше... диалоговое окно класса расширяет контейнер поле wikiPageURL: строка метод showHelp() есть если (wikiPageURL != ноль) // Открытие страницы справки вики. еще супер.showHelp() // Клиентский код. приложение класса // Каждое приложение настраивает цепочку по-своему. метод createUI() есть диалог = новый диалог ("Бюджетные отчеты") dialog.wikiPageURL = "http://..." панель = новая панель (0, 0, 400, 800) panel.modalHelpText = "Эта панель делает..." ок = новая кнопка (250, 760, 50, 20, "ОК") ok.tooltipText = "Это кнопка OK, которая..." отмена = новая кнопка (320, 760, 50, 20, "Отмена") // ... панель.добавить(ок) панель.добавить(отмена) диалог.добавить(панель) // Представьте, что здесь происходит. метод onF1KeyPress() есть компонент = this.getComponentAtMouseCoords() компонент. showHelp()
Применимость
Используйте шаблон цепочки ответственности, когда предполагается, что ваша программа будет обрабатывать различные типы запросов различными способами, но точные типы запросов и их последовательность заранее неизвестны.
Как реализовать
Объявить интерфейс обработчика и описать сигнатуру метода для обработки запросов.
Решите, как клиент будет передавать данные запроса в метод. Самый гибкий способ — преобразовать запрос в объект и передать его методу обработки в качестве аргумента.
Чтобы устранить повторяющийся шаблонный код в конкретных обработчиках, возможно, стоит создать абстрактный базовый класс обработчика, производный от интерфейса обработчика.
Этот класс должен иметь поле для хранения ссылки на следующий обработчик в цепочке. Подумайте о том, чтобы сделать класс неизменяемым. Однако, если вы планируете изменять цепочки во время выполнения, вам необходимо определить установщик для изменения значения поля ссылки.
Вы также можете реализовать удобное поведение по умолчанию для метода обработки, которое заключается в перенаправлении запроса к следующему объекту, если не осталось ни одного. Конкретные обработчики смогут использовать это поведение, вызвав родительский метод.
Один за другим создайте конкретные подклассы обработчиков и реализуйте их методы обработки. Каждый обработчик должен принять два решения при получении запроса:
Будет ли обрабатываться запрос.
Будет ли передаваться запрос по цепочке.
Клиент может либо собирать цепочки самостоятельно, либо получать готовые цепочки от других объектов. В последнем случае необходимо реализовать некоторые фабричные классы для построения цепочек в соответствии с настройками конфигурации или среды.
Клиент может вызвать любой обработчик в цепочке, а не только первый. Запрос будет передаваться по цепочке до тех пор, пока какой-либо обработчик не откажется передавать его дальше или пока он не достигнет конца цепочки.
Из-за динамического характера цепочки клиент должен быть готов к следующим сценариям:
Цепь может состоять из одного звена.
Некоторые запросы могут не достигать конца цепочки.
Другие могут достичь конца цепочки без обработки.
Плюсы и минусы

Связь с другими шаблонами
Chain of Responsibility, Command, Mediator и Observer обращаются к различным способам соединения отправителей и получателей запросов:
Цепочка ответственности передает запрос последовательно по динамической цепочке потенциальных получателей, пока один из них не обработает его.
Команда устанавливает однонаправленные соединения между отправителями и получателями.
Посредник устраняет прямые соединения между отправителями и получателями, заставляя их взаимодействовать косвенно через объект-посредник.
Observer позволяет получателям динамически подписываться на получение запросов и отписываться от них.
Chain of Responsibility часто используется в сочетании с Composite. В этом случае, когда листовой компонент получает запрос, он может передать его по цепочке всех родительских компонентов до корня дерева объектов.
Обработчики в цепочке ответственности могут быть реализованы как команды. В этом случае вы можете выполнять множество различных операций над одним и тем же объектом контекста, представленным запросом.
Однако есть и другой подход, когда сам запрос представляет собой Команда объект. В этом случае вы можете выполнять одну и ту же операцию в ряде различных контекстов, связанных в цепочку.