Парадигма публикации / подписки: почему классы сообщений не должны знать о своих подписчиках?

Из Википедии: «Публикация / подписка (или публикация / подписка) - это парадигма обмена сообщениями, в которой "

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

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

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


publish-subscribe paradigms
person Carl    schedule 25.05.2010    source источник

Ответы (2)


arrow_upward
1
arrow_downward

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

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

С точки зрения совместимости: что происходит, когда новый процесс хочет подписаться на сообщение? Кто несет ответственность за то, чтобы сообщить об этом сообщению (будет ли это по умолчанию для издателя)? И как это новое требование мешает вам сохранять прошлые сообщения для будущего использования, поскольку они не будут знать о будущих подписчиках.

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

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

person Mike    schedule 25.05.2010

arrow_upward
1
arrow_downward

Это просто разделение задач, соблюдение интерфейса и изоляция. Как вы думаете, зачем им знать своих подписчиков?

Сообщение размещается на доске объявлений. Есть несколько досок объявлений разной тематики. Читателей может не быть. Могут быть читатели (подписчики), которые заходят каждый день и проверяют доску на интересующие темы. Может быть, 10 000 читателей прочитают их все.

Если сообщение написано на языке, который, как ожидается, знают читатели, зачем плакату (издателю) или самим сообщениям знать что-либо еще о подписчиках?

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

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

person Joe Koberg    schedule 25.05.2010