Эта статья создана как продолжение описания серии простых паттернов и представляет собой поведенческий паттерн под названием «Цепочка ответственности», который помогает избежать связи между отправителем запроса и его получателем путем добавления одного или нескольких объектов обработки, которые имеют возможность обрабатывать запрос в определенных условиях. манера.
См. Также другие статьи о шаблонах:
Шаблоны создания:
Структурные образцы:
Поведенческие модели:
Цепочка ответственности (эта статья)
Основная суть
Уменьшение сцепления достигается за счет предоставления более чем одному объекту возможности обрабатывать запрос последовательно. Запрос на получение элемента цепочки и после некоторой логики передает запрос следующему обработчику в цепочке обработчиков.
Первый объект в цепочке получает запрос и либо обрабатывает его, либо перенаправляет следующему кандидату в цепочке, что делает то же самое. Объект, отправивший запрос, не знает, кто будет его обрабатывать - у запроса есть неявный получатель.
Этот паттерн включает в себя две основные роли:
- Обработчик - определяет интерфейс для обработки запросов, обрабатывает сам запрос и реализует ссылку-преемник.
- Клиент - инициирует запрос к объекту обработчика в цепочке.
Пример использования
В этом примере мы создадим кофемашину, которая содержит набор обработчиков, которые принимают элемент кофейной чашки для изменения, и ссылку-преемник для передачи управления следующему обработчику в наборе. Каждый элемент кофейной чашки включает внутреннее свойство с именем ingredientsToBeAdded, которое можно представить себе как наклейку в порядке, чтобы бариста (кофемашина в нашем примере) знал, что добавить в кофе. setNewIngredients метод заменит кофейную чашку на новую и установит новые ингредиенты, которые будут добавлены в нее, после чего вы снова сможете processCoffee с обновленным набором ингредиентов.
Выгода
Шаблон «Цепочка ответственности» полезен, если многие объекты должны иметь возможность обрабатывать запрос, а выделенный обработчик неизвестен априори, он будет определен во время выполнения.
Можно не определять конкретный обработчик для запроса явно, а определить набор потенциальных обработчиков для этого запроса. Этот набор объектов для обработки запроса может быть определен динамически во время выполнения. Это освобождает объект от знания, какой объект обрабатывает запрос. Объект должен только знать, что запрос будет обработан надлежащим образом. В результате цепочка ответственности может упростить взаимосвязи объектов.
Добавлена гибкость в назначении функций объектам. Вы можете добавить или изменить обязанности по обработке запроса, добавив или иным образом изменив цепочку во время выполнения.
Слабые места
Цепочка ответственности усложняет логику обработки конкретного запроса. Если конкретный набор обработчиков может быть определен во время выполнения, существует множество форм потенциального результата (мы не можем быть уверены, какой конкретный набор обработчиков появится для конкретного запроса). Таким образом, спрогнозировать конкретный результат, планируя модульные тесты, труднее.
Поскольку у запроса нет явного получателя, нет никакой гарантии, что он будет обработан.
Конфигурацию цепочки ответственности следует производить осторожно. Запрос также может остаться необработанным, если цепочка не настроена должным образом.
Заключение
В настоящее время есть много мест, где нашел место такой узор. Например, в логике оплаты вы должны реализовать разные стратегии, если пользователь является держателем нескольких кредитных карт. В этом случае у нас может быть набор стратегий, и каждая из них будет проверять, применима ли она к конкретной банковской карте.
С другой стороны, Express (NodeJS) или Redux (lib для обработки глобального состояния приложения) имеют особое место для размещения дополнительной логики, которая называется - промежуточное ПО. Эти функции промежуточного программного обеспечения принимают объект текущего состояния и ссылку на преемника (который передает текущее состояние следующему обработчику промежуточного программного обеспечения в наборе промежуточного программного обеспечения).
Цепочка ответственности часто применяется вместе с паттерном Составной. Здесь родительский элемент компонента может выступать в качестве его преемника.
Если вы нашли эту статью полезной, нажмите кнопку 👏 и оставьте комментарий ниже!
