Это было бы конвейером, цепочкой ответственности или чего-то еще?
Я создаю мультиархитектуру процессов, которая, кажется, странная комбинация конвейера и цепочка ответственности. По существу у меня есть цепочка обработчиков, соединенных очередями. Каждый обработчик получит объект, который представляет входные данные, передайте его следующему обработчику так, чтобы это могло начать работать над ним и затем определять, может ли это сделать что-нибудь с теми данными.
Я не полагаю, что могу назвать это конвейером, потому что один шаг действительно не зависит от следующего. Это также, кажется, не традиционная цепочка ответственности, потому что один обработчик не может препятствовать тому, чтобы другие обработчики обработали те данные. Существует ли название этого дизайна, который поможет мне зарегистрировать эту архитектуру? Или я просто оказываюсь перед необходимостью называть его чем-то как "Конвейер Ответственности"?
4 ответа
] Я все еще думаю, что это цепь ответственности, даже при специфике не останавливания цепи. [
] [] Некоторые модели очень похожи, и у них есть вариации. Я думаю, что лучший способ посмотреть, подходит ли тот или иной образец к конкретному случаю, - это посмотреть на его намерение. Из книги GoF:[
] [] [] [] Цепь ответственности "Избегать соединить отправителя запроса с его получатель, отдавая более одного возражать против возможности обработать запрос. Свяжите принимающие объекты и пройдите запрос по цепочке до объект справляется с этим". (стр.223)[
] [
]Так что если нет связи между вашим обработчиком и объектами, проходящими через цепочку, я не думаю, что имеет значение, что объект всегда будет падать до конца цепочки, даже если с ним обращаются.[
].] Судя по вашему описанию, это что-то другое. Как цепочка ответственности, так и трубопровод по сути имеют дело с серийной обработкой. По крайней мере, если я правильно понимаю ваше описание, то, что у вас есть, это, по сути, ряд "элементов процессора", работающих над данными параллельно.[
] [] Обычно вы бы справились с подобной ситуацией с набором наблюдателей, но ваше описание тоже не совсем соответствует шаблону наблюдателя. В частности, кажется, что каждый из элементов вашего процессора знает (по крайней мере) еще об одном элементе процессора. С шаблоном наблюдателя наблюдатели обычно забывают друг о друге - каждый регистрирует себя с источником данных, а когда появляются новые/изменяющиеся данные, все наблюдатели уведомляются источником данных.[
] []Моей непосредственной реакцией было бы то, что вам, вероятно, лучше использовать шаблон наблюдателя вместо того, чтобы искать имя для того, что вы сделали. Одним из пунктов паттерна является решение подобных проблем подобными способами. Судя по звучанию вещей, это, наверное, было бы более универсально и управляемо. Например, если вы решили исключить одного наблюдателя из цепочки, то, очевидно, вам придется изменить другого наблюдателя, чтобы сделать это. С помощью обычного шаблона наблюдателя вы можете добавлять или удалять наблюдателей, не изменяя других (и даже не зная, что что-то вообще изменилось).[
] []Редактирование: Учитывая смесь независимых и цепочечных элементов, я вижу два возможных варианта. Первый (и, вероятно, самый чистый) - это использование шаблона наблюдателя на верхнем уровне, а некоторые наблюдатели сами будут трубопроводами.[
] []Другая возможность - это кража трюка с VLIW-процессоров, а на верхнем уровне - флаг, указывающий, зависит ли конкретный элемент от результата от предыдущего или нет. Это позволяет довольно легко смешивать конвейеры с независимыми наблюдателями, и если (например) какое-то время вы заботитесь о параллельной обработке, то довольно легко выполнять независимые процессы параллельно, сохраняя последовательное выполнение для тех, кто в этом нуждается.[
].] Это больше похоже на [] образец наблюдателя [], так как каждый обработчик уведомляется о том, что происходит изменение со входа (через событие, содержащее данные)[
].Я думаю, что это Доска
см. Этот ответ на аналогичный вопрос