Paradigms 发布/订阅范例：为什么消息类不知道它们的订阅者？

From：“发布/订阅（或发布/订阅）是一种消息传递范例，其中消息的发送者（发布者）未编程为将其消息发送给特定的接收者（订阅者）。相反，已发布的消息被划分为类，而不知道可能存在哪些订阅者（如果有的话）。”

我可以理解为什么发送者不能被编程为将其消息发送给特定的接收者。但为什么发布的消息必须是不知道订阅者的类呢

似乎一旦消息传递系统本身就位，通常随着软件的发展而改变的是发送的消息、发布者和接收者。将消息与订阅者分开似乎意味着订阅模型也可能会改变。这是原因吗？还有，这在现实世界中发生了吗

---

我意识到这可能是一个基本的问题，但我试图理解这个范例，非常感谢您的回答

这只是关注点的分离、对接口的坚持和隔离。你认为他们为什么需要了解订户

一条消息贴在布告栏上。有多个不同主题的公告栏。可能没有读者。可能有读者（订阅者）每天都会来查看黑板上感兴趣的话题。可能有10000名读者全部阅读了这些内容

只要信息是用读者希望知道的语言编写的，为什么海报（出版商）或信息本身需要了解订阅者的其他信息

我认为消息已经了解了消息的接口/契约接收者，但仅此而已

---

似乎这个模型也允许单向信息流。。。为了了解您的订阅者，必须有双向的信息流。

我认为这条规则无论如何都不是绝对的，如果您发现了解订阅者的信息有用，我不认为任何人会告诉您您错了（但他们可能会告诉您有更好的方法）

但是，请记住，可伸缩性和向后兼容性将直接受到消息对其订阅者的感知的影响

兼容性方面，当一个新进程想要订阅一条消息时会发生什么？谁负责让消息知道（这会默认为发布者）？这个新的需求如何阻止您保存过去的消息以供将来使用，因为他们不会知道未来的订阅者

就可伸缩性而言，当您的消息系统变得流行，每个人和他们的母亲开始为您的应用开发不同的订户（如twitter）时，会发生什么？如何处理发送一千次（每个订阅客户端发送一条）或发送一条更大的消息的每条消息？这可能会妨碍您使用其他技术，如SMS，或为可靠的传输技术创建更大的延迟

这可能是为了避免以后的头痛