Это статья о Шаблоне проектирования цепочки ответственности, в котором у нас есть отправитель и несколько получателей для обработки сообщения, которое отправитель отправляет получателю1, если получатель2 способен обработать сообщение, а затем получатель 1 отправляет его получатель 2 и так далее, если получатель 3 не может обработать сообщение, и сообщение будет отправлено обратно отправителю.
Чтобы лучше понять это, давайте рассмотрим пример из реальной жизни, предположим, что вы стажер в какой-то компании XYZ, и несколько дней назад вы задержались в офисе, чтобы решить какую-то важную производственную проблему, поэтому вы заказали такси, чтобы вернуться домой, и теперь вы хотите чтобы возместить сумму в 1000 индийских рупий за забронированное вами такси.
Но вот загвоздка: если возмещаемая сумма меньше или равна 500 индийских рупий, она может быть одобрена старшим разработчиком в команде, если сумма больше 500 или меньше или равна 1000 индийских рупий, то она может быть одобрена. руководителем группы, а любая другая сумма, превышающая 1000 индийских рупий, должна быть одобрена менеджером.
Я надеюсь, что теперь у нас есть представление о том, где использовать этот шаблон проектирования, где запрос проходит через различные приемники для обработки.
Итак, в компании XYZ используется одно веб-приложение, и вся вышеперечисленная логика уже реализована в нем с помощью шаблона проектирования цепочки ответственности.
Давайте перейдем к фактической реализации, давайте сначала создадим следующий интерфейс:
Здесь nextChain() предназначена для установки следующего обработчика получателя/запроса, а approveAmount() предназначена для обработки нашего бизнеса, когда мы решаем, обрабатывать ли запрос или направлять его в следующий получатель/обработчик запроса.
Теперь пришло время реализовать описанный выше интерфейс классами, которые будут обрабатывать запрос на утверждение суммы возмещения.
Теперь в нашем основном классе зададим цепочку и количество для обработки:
Здесь цепочка SeniorDev -> TeamLead -> Manager. Поскольку SeniorDev является первым в цепочке, запрос сначала придет к нему.
Но сумма в 1000 индийских рупий будет одобрена TeamLead, потому что SeniorDev может утвердить сумму до 500 индийских рупий.
Преимущества:
- Это уменьшает сцепление.
- Упрощенный объект. Объекту не нужно знать структуру цепочки.
- Увеличение обработки запросов новым классом очень удобно.
- Повышение гибкости возложенных на объект обязанностей. Изменяя членов в цепочке или изменяя их порядок, разрешайте динамическое добавление или удаление ответственности.
Недостатки:
- Запрос должен быть получен не гарантия.
- Это повлияет на производительность системы, но также непростая отладка кода может вызвать вызов цикла.
- Из-за отладки может быть непросто наблюдать за характеристиками работы.
Если вам понравилась эта статья, пожалуйста, похлопайте нам и, пожалуйста, подпишитесь на нас. И следите за новыми статьями.
