Определение: позволяет нескольким объектам иметь возможность обрабатывать запрос, избегая тем самым взаимосвязи между отправителем и получателем запроса. Подключите эти объекты в цепь и передайте запрос вдоль цепочки, пока объект не обработает его.
Тип: поведенческий паттерн
Классовая диаграмма:
Давайте сначала посмотрим на кусок кода:
public void test (int i, запрос запроса) {if (i == 1) {Handler1.Response (запрос); } else if (i == 2) {handler2.response (запрос); } else if (i == 3) {handler3.response (запрос); } else if (i == 4) {handler4.response (запрос); } else {handler5.response (запрос); }} Бизнес -логика кода заключается в следующем: метод имеет два параметра: целое число I и запрос на запрос. Согласно значению I, который будет обрабатывать запрос, если i == 1, он будет обрабатываться Handler1, если я == 2, он будет обрабатываться Handler2 и так далее. В программировании этот вид метода обработки бизнеса очень распространен. Все классы, которые запросы процесса, включают в себя, если ... else ... условные заявления о суждении, связанные с цепочкой ответственности для обработки запроса. Я верю, что все это часто используют. Преимущества этого метода заключается в том, что он очень интуитивно, прост и ясен и относительно прост в поддержании, но этот метод также имеет несколько головных болей:
Код раздутый: в фактических приложениях условия суждения обычно не так просты для определения того, составляет ли это 1 или 2. Это может потребовать сложных вычислений, возможно, запроса базы данных и т. Д. Это будет иметь много дополнительного кода. Если есть много условий суждения, то это, если ... иначе ... утверждение в основном невозможно прочитать.
Высокая степень связи: если мы хотим продолжать добавлять классы, которые запрашиваются, мы должны продолжать добавлять иначе, если условия суждения; Кроме того, порядок этого условия также записывается мертвым. Если мы хотим изменить заказ, мы можем только изменить это оператор условия.
Поскольку мы уже поняли недостатки, нам нужно найти способ их решить. Бизнес -логика этого сценария очень проста: если условие 1 будет выполнено, она будет обработана Handler1, и если он не будет выполнен, оно будет передано; Если условие 2 будет выполнено, оно будет обработано Handler2, и если оно не будет выполнено, оно будет передано, и так далее до конца состояния. Фактически, метод улучшения также очень прост, который заключается в том, чтобы поместить часть условий суждения в класс обработки. Это принцип модели связи ответственности.
Структура модели компании ответственности
Классовая диаграмма схемы, связанного с ответственностью, очень проста, она состоит из абстрактно обработанного класса и его набора классов реализации:
Класс абстрактной обработки: класс абстрактной обработки в основном включает в себя переменную члена Nexthandler, указывающая на следующий класс обработки, и метод HandRequest, который обрабатывает запрос. Основная идея метода HandRequest заключается в том, что если условия обработки будут выполнены, этот класс обработки будет обработан, в противном случае он будет обработан Nexthandler.
Конкретный класс обработки: конкретный класс обработки в основном реализует конкретную логику обработки и применимые условия для обработки.
Пример
Модель цепочки ответственности имеет две роли:
Роль абстрактного обработчика: определяет запрошенный интерфейс. При необходимости вы можете определить метод для установки и вернуть ссылку на следующий домашний объект.
Роль ConcretHandler: если она может быть обработана, обработайте запрос. Если он не может быть обработан, передайте запрос следующему дому и позвольте следующему дому справиться с ним. То есть он обрабатывает запросы, которые могут обрабатывать, и может получить доступ к следующему дому.
Тестовый код для приведенной выше шаблона заключается в следующем:
Package chainofresp;/***Описание: Абстрактная обработка роли*/public Abstract Class Handler {Защищенный преемник обработчика; / ***Описание: Метод обработки*/ public Abstract void handlerRequest (строковое условие); Public Handler getSuccessor () {return преемник; } public void setSuccessor (преемник обработчика) {this.successor = преемник; }} package chainOfResp;/** *Description: Detailed handling of roles*/public class ConcreteHandler1 extends Handler { @Override public void handlerRequest(String condition) { // If it is your own responsibility, you will handle it yourself and be responsible for passing it to the next home if(condition.equals("ConcreteHandler1")){ System.out.println( "ConcreteHandler1 handled "); возвращаться ; } else {System.out.println ("ConcreteHandler1 прошел"); GetSuccessor (). HasterLerRequest (условие); }}} Package chainofresp;/***Описание: Подробная обработка ролей*/public Class ConcreteHandler2 Extends handler {@Override public void ghoodlerRequest (Строка) {// Если это ваша собственная ответственность, вы будете справляться с ним сами и несете ответственность за передачу его следующему дому, если (Condition.Equals ("ConcreteHandler2")) {System.out.println ("Condition.Equals (" ConcreteHandler2 ")) {System.out.Println (" Condition.Equals ("ConcreteHandler2")) {System.out.Println ("Condite.Equals. возвращаться ; } else {System.out.println ("ConcreteHandler2 прошел"); GetSuccessor (). HasterLerRequest (условие); }}} Package chainofresp;/*** Описание: Подробная роль обработки*/public class concretehandlern extends handler {/*** Здесь предполагается, что n - последний узел цепочки, который должен обрабатывать* в реальных ситуациях, может появиться кольцо или дерево,* это не обязательно последний узел. * */ @Override public void handlerRequest (String Condity) {System.out.println ("ConcreteHandlern Grandled"); }} Package chainofresp;/***Описание: тестовый класс*/public class client {/***Описание:*/public static void main (string [] args) {Handler handler1 = new ConcretHandler1 (); Обработчик Handler2 = новый ConcretHandler2 (); Handler Handlern = new ConceteHandlern (); // Цепочный обработчик1.setsuccessor (Handler2); Handler2.setSuccessor (Handlern); // Предположим, что этот запрос является обязанностью обработчика ConcretHandler2.HandlerRequest ("ConcretHandler2"); }}
Чтобы привести этот пример, в производственном семинаре на игрушечной фабрике, линия сборки является цепочкой ответственности. Если самолет для игрушек имеет ассемблер оболочки, ассемблер двигателя, ассемблер пропеллера и модель -упаковщик. Когда самолет перетекает к тому, к кому вытекает объект, он будет нести ответственность за установку части, за которую он отвечает. После того, как эта часть будет установлена, она будет переходить к следующему шагу и узнает, что все среды завершены. Это цепочка ответственности, которая генерируется. Существует также цепочка качества, которая разделена на несколько деталей, осмотр оболочки, проверку двигателя, проверку винта и проверку упаковки. Когда продукт остается инспектору, чтобы проверить часть, за которую он отвечает, если есть какие -либо проблемы, он будет непосредственно выведен. Если нет проблем, он будет передан следующему инспектору до тех пор, пока все тесты не будут завершены. Эти двое являются цепочками ответственности, но разница в том, что каждый будет обрабатывать цепочку ответственности и обрабатывать ее часть; В то время как после суждения цепочка ответственности за качественную проверку будет либо обрабатываться, либо не обрабатывать. Это две категории цепочек ответственности. Последнее называется чистыми цепочками ответственности, а первое называется нечистыми цепями ответственности. Чистые цепочки ответственности редко существуют в практических приложениях. Обычным являются нечистые цепочки ответственности. Приведенная выше модель имитирует чистые цепи ответственности, чтобы справиться.
Плюсы и минусы модели цепочки ответственности
По сравнению с if ... else…, шаблон цепочки ответственности обладает более низкой способностью к связи, потому что он распределяет условные суждения в различные классы обработки, и порядок обработки приоритетов этих классов обработки может быть установлен по желанию. Модель цепочки ответственности также имеет свои недостатки, которые совпадают с утверждением if ... else ... то есть, прежде чем найти правильный класс обработки, все условия суждения должны быть выполнены. Когда цепочка ответственности является относительно длинной, проблема с производительностью является более серьезной.
Применимые сценарии для модели цепочки ответственности
Так же, как в начальном примере, если вы чувствуете себя подавленным при использовании оператора if… else ... для организации цепочки ответственности, а код выглядит плохо, вы можете использовать режим цепочки ответственности, чтобы рефактор его.
Суммировать
Модель цепочки ответственности на самом деле является гибкой версией if ... else ... Заявление. Это помещает эти условия суждения в каждый класс обработки. Преимущество этого в том, что это более гибкое, но также вызывает риск. Например, при настройке взаимосвязи между классом обработки до и после класса обработки вы должны быть очень осторожны, чтобы судить о взаимосвязи между условной логикой до и после класса обработки, и быть осторожным, чтобы не иметь круговых ссылок в цепочке.