Шаблоны проектирования, часть 5: шаблон цепочки ответственности

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

Как видно из приведенной выше диаграммы, запрос будет принят обработчиками и будет передан каждому обработчику в зависимости от условия. Цепочка или ответственность могут быть реализованы для выполнения задач, которые будут выполнять задачи синхронно между обработчиками (результаты предыдущего обработчика будут использоваться в следующем обработчике) или полностью независимыми обработчиками, которые будут выполнять свои собственные задачи в соответствии со спецификациями.

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

РЕАЛИЗАЦИЯ

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

Теперь давайте посмотрим на реализацию указанной выше проблемы. Сначала создадим бюджетный класс. Приведенный ниже код является реализацией класса Budget.

Класс бюджета будет иметь имя сотрудника и стоимость для его бюджета. У этого класса также будут геттеры и сеттеры.

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

У абстрактного класса будет собственный экземпляр для хранения указателя на следующего преемника в цепочке (например, связанный список), у нас будет сеттер для установки следующего обработчика в цепочке, а также будет абстрактный метод, который будет проверять, если бюджет может быть утвержден или передан следующему обработчику. Теперь, когда у нас есть базовый класс, давайте создадим классы ShiftLead, TeamLead и Manager, которые будут расширять вышеуказанный абстрактный класс.

Вышеупомянутые классы будут нашими классами-обработчиками, и каждый будет проверять бюджет. Если они могут утвердить бюджет, они вернут свое утверждение в виде строки, а если они не могут утвердить бюджет, они передадут его следующему обработчику. Процесс показан ниже на простой схеме.

Мы также создадим другой обработчик, который будет отправной точкой, и я назову его BudgetCheck.

Теперь, когда у нас есть эти классы, пришло время реализовать основной метод.

Вышеупомянутый основной метод для этого приложения. Как видно выше, мы создаем экземпляры для обработчиков от строки № 4 до строки № 6. И я устанавливаю преемников со строки № 9 до 11, вызывая метод setSuccessor(). После этого я создаю разные экземпляры бюджета с разными затратами, а затем вызываю checkEligibility() метод экземпляра класса BudgetCheck bc. Результат будет таким:

Как видно из вышеприведенного вывода, разные обработчики печатают значение в соответствии с переданным значением. Некоторые из вас, должно быть, думают, зачем использовать Chain Of Responsibility, когда мы также можем делать if else. Представьте, что вы хотите убрать ShiftLead из логики. Если вы реализовали это с помощью if else, вы войдете в логику кода и внесете в нее изменения, но, реализовав как Design Of Responsibility, нам просто нужно изменить одну строку нашего кода, которая: bc.setSuccessor(tl). Мы также можем добавлять новые обработчики и удалять обработчики, не затрагивая основную логику.

КЛЮЧЕВЫЕ МОМЕНТЫ

Теперь, когда мы знаем реализацию шаблона проектирования «Цепочка ответственности», давайте взглянем на некоторые ключевые моменты.

Слабая связь: Слабая связь означает, что существование одного объекта не полностью зависит от другого. Это улучшает масштабируемость вашего проекта. Это означает, что компонент может быть изменен без изменения всего основного кода.
Легко добавлять новые обработчики и изменять порядок: в этом шаблоне проектирования мы можем легко добавлять новые обработчики, а также изменять порядок операций в зависимости от наших потребностей.
Если для определенного ответа нет обработчика, шаблон проектирования просто проигнорирует его.
Основным преимуществом этого шаблона проектирования является также его главный недостаток, конечный разработчик может изменить порядок цепочки.
Этот шаблон проектирования реализован в классе регистратора в JDK. Мы можем проверить это, установив уровень журнала с помощью функции setLevel(), а затем вызвав функцию log().

Теперь, когда мы знаем о ключевых моментах этого шаблона проектирования, осталось еще кое-что, о чем нужно знать, где использовать этот шаблон проектирования. Этот шаблон проектирования можно использовать в тех местах, где процесс основан на разрешениях, таких как система, которую я реализовал выше. Другой пример - система, которая будет рассчитывать зарплату в зависимости от должности, рабочего времени, а также проекта, над которым работал сотрудник.

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

Часть 1: Обзор шаблонов проектирования и одноэлементного шаблона проектирования.

Часть 2: Factory Design Pattern

Часть 3: Шаблон проектирования прототипа

Часть 4: шаблон проектирования Builder

Спасибо за чтение 😃.