Обработка запроса несколькими обработчиками в схеме цепочки ответственности

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

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

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

Постановка задачи

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

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


java design-patterns chain-of-responsibility gang-of-four
person Praveen Banthia    schedule 19.06.2017    source источник

Ответы (2)


arrow_upward
3
arrow_downward

Я не знаю, сделать ли это ответом или комментарием, но:

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

В конвейере идея состоит в том, что все шаги будут, по крайней мере, просматривать данные, хотя они могут фактически не выполнять какую-либо обработку данных. Обычно неявное понимание состоит в том, что конвейер является «линейным».

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

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

Конечно, есть некоторые соображения, о которых стоит подумать: как только какой-либо отдел отклоняет запрос, должно ли в системе короткое замыкание? Есть ли в игре сложная бизнес-логика, что-то вроде одобрения отдела A и C, отказа B и отказа отдела D от голосования до крайнего срока — теоретическое состояние, которое необходимо обработать?

Я набрал это на телефоне перед сном, так что простите за ошибки в ответе. Завтра вернусь, посмотрю и почищу, если нужно.

person Hangman4358    schedule 19.06.2017

arrow_upward
1
arrow_downward

Шаблон стратегии больше подходит для вашего случая.

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

  • оплаченный

  • одобренный

  • в ожидании утверждения

  • на рассмотрении

  • черновик

    и т.п.

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

Суперкласс (интерфейс/абстрактный) может иметь такие методы, как:

needsAction()     : boolean
ownerDepartment() : Department // department it should go to next

Тогда каждый подкласс будет определять собственную логику для этих методов.

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

person Nishant    schedule 19.02.2018