Будет ли это конвейер, цепочка ответственности или что-то еще?

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

Я не думаю, что могу назвать это конвейером, потому что один шаг на самом деле не зависит от следующего. Это также не похоже на традиционную цепочку ответственности, потому что один обработчик не может помешать другим обработчикам обрабатывать эти данные. Есть ли имя для этого проекта, которое поможет мне задокументировать эту архитектуру? Или мне просто придется называть это как-то вроде «Конвейер ответственности»?


person Jason Baker    schedule 05.01.2010    source источник


Ответы (3)


Я все еще думаю, что это цепочка ответственности, даже с учетом того, что цепочку нельзя останавливать.

Некоторые шаблоны очень похожи, и у них есть вариации. Я думаю, что лучший способ увидеть, подходит ли шаблон к делу, — это посмотреть на его намерение. Из книги ГФ:

Цепочка ответственности «Избегайте связывания отправителя запроса с его получателем, давая более чем одному объекту возможность обработать запрос. Связывайте принимающие объекты и передавайте запрос по цепочке, пока объект не обработает его». (стр. 223)

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

person Padu Merloti    schedule 05.01.2010

Судя по твоему описанию, это что-то другое. И цепочка ответственности, и конвейер имеют дело с последовательной обработкой. По крайней мере, если я правильно понимаю ваше описание, у вас есть в основном ряд «элементов процессора», работающих с данными параллельно.

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

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

Редактировать: Учитывая смесь независимых и цепных элементов, я вижу два возможных варианта. Первый (и, вероятно, самый чистый) — использовать шаблон наблюдателя на верхнем уровне, а некоторые из наблюдателей сами будут конвейерами.

Другой возможностью было бы украсть трюк у процессоров VLIW и на верхнем уровне иметь флаг, указывающий, зависит ли конкретный элемент от результата предыдущего или нет. Это позволяет довольно легко смешивать конвейеры с независимыми наблюдателями, и если (например) какое-то время вы заботитесь о параллельной обработке, довольно легко выполнять независимые процессы параллельно, сохраняя при этом последовательное выполнение для тех, кто в этом нуждается.

person Jerry Coffin    schedule 05.01.2010
comment
Я думаю, что это случай выбора между меньшим из двух зол. Я согласен с тем, что лучше всего использовать шаблон Observer напрямую, но есть несколько этапов, которые делают составляют конвейер. И я чувствую, что если они все вписываются в один и тот же всеобъемлющий дизайн, все становится более понятным. - person Jason Baker; 06.01.2010
comment
К вашему сведению, альтернативой, вероятно, будет что-то вроде того, что компонент, который отправляет сообщения наблюдателям, будет последним компонентом в конвейере. Это могло бы сработать, но я чувствую (как личное мнение), что эта установка наиболее понятна. Имейте в виду, что в этой архитектуре параллелизм раньше не использовался, поэтому наличие некоторой последовательности, скорее всего, облегчит понимание. - person Jason Baker; 07.01.2010

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

person akf    schedule 05.01.2010
comment
Я не думал об этом таким образом. Я полагаю, это имеет смысл. - person Jason Baker; 05.01.2010
comment
Если я правильно понял, у него уже цепочка объектов вместо какой-то рассылки сообщений, да? - person Padu Merloti; 06.01.2010
comment
Я думаю, что ключ к шаблону COR заключается в том, что событие передается до тех пор, пока кто-то его не обработает, а затем оно больше не пересылается. В примере OP все обработчики в очереди обрабатывают событие, так что это своего рода широковещательная рассылка. - person akf; 06.01.2010
comment
Да я вижу. Тогда единственная существенная разница будет заключаться в том, важен ли порядок, в котором объект получен обработчиками. - person Padu Merloti; 06.01.2010
comment
да. В этом примере присутствует строгое упорядочение, которого нет в Observer. Я должен был более четко объяснить, почему я считаю, что дизайн Джейсона напоминает Observer, а не цепочку ответственности, хотя и не идеально подходит. - person akf; 06.01.2010