Обмен технологиями

Шаблон проектирования цепочки ответственности

2024-07-12

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Шаблон «Цепочка ответственности» — это шаблон поведенческого проектирования, который позволяет нескольким объектам обрабатывать запросы последовательно, и каждый объект может выбирать, обрабатывать ли запрос или передавать его следующему объекту. Этот шаблон обеспечивает большую гибкость и масштабируемость за счет разделения отправителя и получателя запросов. Ниже приводится подробное введение в модель цепочки ответственности:

1. Определение и основные идеи

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

2. Диаграмма классов и основные роли

Диаграмма классов:

Модель цепочки ответственности в основном включает в себя следующие роли:

  1. Абстрактный обработчик (Handler) : Определить интерфейс для обработки запросов. При необходимости интерфейс может определить метод для установки и возврата ссылки на следующий интерфейс. Эта роль обычно реализуется абстрактным классом или интерфейсом.

  2. Бетонный манипулятор : после получения запроса конкретный процессор может решить обработать запрос или передать запрос следующей стороне. Поскольку конкретный процессор содержит ссылку на следующий дом, при необходимости он может получить доступ к следующему дому.

  3. Клиентский класс (Клиент): Создайте цепочку обработки и отправьте запрос конкретному объекту процессора головы цепочки.

3. Применимые сценарии

Модель цепочки ответственности подходит для следующих сценариев:

  1. Несколько объектов совместно обрабатывают задачу: Например, многоуровневая система утверждения передает запрос на утверждение следующему уровню утверждающего в зависимости от его полномочий и уровня до тех пор, пока не будет получен окончательный результат утверждения.

  2. Процесс обработки динамической комбинации: Благодаря гибкой настройке цепочки ответственности объекты обработки можно динамически комбинировать для реализации различных процессов обработки.

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

4. Преимущества и недостатки

преимущество
  1. Уменьшите сцепление: он разделяет отправителя и получателя запроса. Запрос только отправляется, независимо от того, кто его обрабатывает.
  2. Повышенная гибкость назначения объектов.: позволяет динамически добавлять или удалять обязанности путем изменения участников внутри цепочки или перемещения их заказа.
  3. Упрощение объектов: объекту не обязательно знать структуру цепочки.
  4. Удобно добавлять новые классы обработки запросов.: Следуя принципу открытия и закрытия, новые процессоры могут быть добавлены в цепочку ответственности в любое время без изменения существующего кода, что обеспечивает хорошую масштабируемость.
недостаток
  1. Нет никакой гарантии, что запрос будет принят.: Если цепочка ответственности настроена неправильно или процессор неправильно обрабатывает запрос, запрос может не быть обработан.
  2. Проблемы с производительностью: Если цепочка ответственности слишком длинная или запросы часто передаются в цепочке ответственности, это может повлиять на производительность.
  3. Отладка неудобна: Когда цепочка ответственности особенно длинная и имеет много звеньев, логика при отладке может усложняться из-за рекурсивного подхода.

5. Сценарии применения

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

  1. Система регистрации: передавать сообщения журнала в разные средства ведения журнала в соответствии с уровнем журнала, например, в консольное средство ведения журнала, в файловое средство ведения журнала, в средство ведения журнала базы данных и т. д.
  2. Система обработки исключений: классифицируйте исключения по их типам, например ведение журнала, уведомления по электронной почте, отображение исключений и т. д.
  3. Многоуровневая система одобрения: например, утверждение отпуска, утверждение покупки и т. д., запрос на утверждение передается утверждающему лицу следующего уровня в соответствии с полномочиями и уровнем утверждающего.

6. Примеры реализации

Ниже приведен простой пример реализации шаблона цепочки ответственности, который используется для обработки сообщений журнала и передачи сообщений различным процессорам в соответствии с уровнем журнала (например, DEBUG, INFO, WARN, ERROR):

  1. // 抽象处理者
  2. abstract class LogHandler {
  3. protected int level;
  4. protected LogHandler nextHandler;
  5. public void setNextHandler(LogHandler nextHandler) {
  6. this.nextHandler = nextHandler;
  7. }
  8. //这个是精髓:他除了处理自己的逻辑,还会调用nextHandler进行处理
  9. public void logMessage(int level, String message) {
  10. if (this.level <= level) {
  11. write(message);
  12. }
  13. if (nextHandler != null) {
  14. nextHandler.logMessage(level, message);
  15. }
  16. }
  17. abstract protected void write(String message);
  18. }
  19. // 具体处理者:ErrorLogHandler
  20. class ErrorLogHandler extends LogHandler {
  21. public ErrorLogHandler(int level) {
  22. this.level = level;
  23. }
  24. @Override
  25. protected void write(String message) {
  26. System.out.println("ErrorLogHandler: " + message);
  27. }
  28. }
  29. // 具体处理者:WarnLogHandler
  30. class WarnLogHandler extends LogHandler {
  31. public WarnLogHandler(int level) {
  32. this.level = level;
  33. }
  34. @Override
  35. protected void write(String message) {
  36. System.out.println("WarnLogHandler: " + message);
  37. }
  38. }
  39. // 具体处理者:InfoLogHandler
  40. class InfoLogHandler extends LogHandler {
  41. public InfoLogHandler(int level) {
  42. this.level = level;
  43. }
  44. @Override
  45. protected void write(String message) {
  46. System.out.println("InfoLogHandler: " + message);
  47. }
  48. }
  49. // 客户端代码
  50. public class ChainPatternDemo {
  51. private static LogHandler getChainOfLoggers() {
  52. // 创建链中的处理者
  53. LogHandler errorLogHandler = new ErrorLogHandler(3);
  54. LogHandler warnLogHandler = new WarnLogHandler(2);
  55. warnLogHandler.setNextHandler(errorLogHandler);
  56. LogHandler infoLogHandler = new InfoLogHandler(1);
  57. infoLogHandler.setNextHandler(warnLogHandler);
  58. return infoLogHandler;
  59. }
  60. public static void main(String[] args) {
  61. LogHandler loggerChain = getChainOfLoggers();
  62. loggerChain.logMessage(1, "This is an informational message.");
  63. loggerChain.logMessage(2, "This is a warning message.");
  64. loggerChain.logMessage(3, "This is an error message.");
  65. }
  66. }

В этом примере мы определяем три конкретных класса обработчиков журналов (ErrorLogHandlerWarnLogHandlerInfoLogHandler ), они обрабатывают разные уровни сообщений журнала соответственно. Каждый обработчик содержит уровень (level ), используемый для определения необходимости обработки сообщений этого уровня.ПозвонивlogMessageметод, запрос передается первому обработчику в цепочке (infoLogHandler ), он решает, обрабатывать ли сообщение, исходя из своего собственного уровня и логики обработки, а затем (если не обработан) передает запрос следующему процессору в цепочке. Этот процесс продолжается до конца цепочки или до тех пор, пока запрос не будет обработан.

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

7. Заключение

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

Если модель цепочки ответственности вам полезна, не забудьте поставить лайк и сохранить ее.