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

Question

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

Шаблон, на котором я остановился, - это Chain Of Responsibility Pattern. Из того, что я понимаю, есть запрос, переданный одному обработчику, который будет обрабатывать запрос или передавать его по цепочке.

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

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

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

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

Answer 1

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

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

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

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

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

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

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

Answer 2

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

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

• оплаченный
• одобренный
• в ожидании утверждения
• на рассмотрении

• проект

  и т.п.

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

Суперкласс (interface/abstract) может иметь такие методы, как:

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

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

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