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

Question

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

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

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

Answer 3

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

Answer 4

Я думаю, что это Доска

см. ответ на аналогичный вопрос