Цепочка обязанностей (`Chain of Responsibility`)¶

Chain of Responsibility передает запрос по цепочке обработчиков, пока один из них не возьмет его на себя.

Опора на ООП¶

Chain of Responsibility опирается на полиморфизм и интерфейсы: каждое звено реализует общий контракт обработки, а клиент не знает, какое именно звено сработает. Инкапсуляция помогает локализовать отдельный шаг обработки внутри конкретного звена.

Что показывает пример на 1С¶

DataProcessors.BaseHandler хранит NextHandler, умеет делать SetNext() и по умолчанию делегирует Handle(Request) дальше.
DeserializePartnerHandler, DeserializeProductsHandler и DeserializeWarehouseHandler проверяют, их ли это запрос, и либо обрабатывают его, либо отдают следующему звену.
Такая структура особенно понятна в сценариях разбора входящих сообщений или каскадной валидации.

Пример¶

DataProcessors.BaseHandlerDataProcessors.DeserializePartnerHandler

Var NextHandler;

#Region Public

Function SetNext(Handler) Export

    NextHandler = Handler;
    Return Handler;

EndFunction

Function Handle(Request) Export

    If NextHandler <> Undefined Then
        NextHandler.Handle(Request);
    EndIf;

    Return Undefined;

EndFunction

#EndRegion

Var Super;

#Region Public

Function Init(Super_) Export

    Super = Super_;
    Return ThisObject;

EndFunction

Function Handle(Request) Export

    If IsPartner(Request) Then
        Return Deserialize(Request);
    EndIf;

    Return Super.Handle(Request);

EndFunction

#EndRegion

Вариации¶

У Chain of Responsibility на практике есть как минимум две очень разные формы.

1. Цепочка выбора обработчика¶

Это классический вариант: каждый обработчик решает, его это запрос или нет.

если обработчик подходит, он забирает запрос себе;
если не подходит, передает дальше;
в нормальном случае реальную работу выполняет только одно звено цепочки.

Именно такой вариант показан в текущем примере с DeserializePartnerHandler, DeserializeProductsHandler и DeserializeWarehouseHandler: цепочка ищет, кто именно должен разобрать входящие данные.

Такой стиль полезен, когда:

нужно определить тип входящего сообщения;
выбор зависит от правил или формата данных;
важна расширяемость без большого Если ... ИначеЕсли.

2. Цепочка обязательного pipeline¶

Во второй вариации звенья не выбирают "кто из нас обработает запрос", а последовательно прогоняют его через обязательные шаги.

каждое звено делает свою часть работы;
после этого почти всегда передает управление дальше;
итоговый результат формируется после прохождения всей цепочки.

Для 1С это может быть, например:

валидация данных;
нормализация входного пакета;
обогащение служебными полями;
проверка прав;
только потом основная обработка или запись.

Такой вариант ближе не к маршрутизации, а к pipeline. Он полезен, когда все условия обязательны и их нужно проходить в фиксированном порядке до основной операции.

Частный случай такого pipeline в 1С можно увидеть в обработке подписок на события объектов метаданных. По сути, объект последовательно проходит через несколько обязательных обработчиков, каждый из которых выполняет свою часть проверки, подготовки или синхронизации данных.

Как различать эти варианты¶

Цепочка выбора отвечает на вопрос: кто должен это обработать?
Цепочка-pipeline отвечает на вопрос: какие обязательные шаги нужно пройти до обработки?

Снаружи они могут выглядеть похоже, но архитектурно это разные сценарии. В первом случае обычно ищется одно подходящее звено, во втором почти вся цепочка должна отработать целиком.

Где полезен в 1С¶

при маршрутизации входящих пакетов из интеграций;
при многошаговой проверке данных перед записью;
при последовательной попытке разных способов обработки.

Когда паттерн лишний¶

если обработчиков один-два и порядок не меняется;
если проще и яснее оставить таблицу соответствий или Если ... ИначеЕсли;
если поведение цепочки непрозрачно и трудно отлаживается.

Источник примера¶

zeegin/DesignPatterns: ChainOfResponsibility

Цепочка обязанностей (Chain of Responsibility)¶