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

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

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

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

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

Ответы [ 2 ]

1 голос
/ 26 мая 2010

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

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

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

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

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

1 голос
/ 26 мая 2010

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

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

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...