oop - 为什么观察者设计模式通常被描绘成一对多?

标签 oop design-patterns observer-pattern software-design

在研究中 Observer pattern我注意到,Subject 之间的连接和 Observer通常是一对多。为什么这样?多对多关系会导致任何问题有什么特别的原因吗?

最佳答案

使用观察者设计模式设计的系统旨在为主体提供具有多个观察者的便利,并在主体状态发生变化时通知他们。那是教科书的定义。

让我们看一个真实世界的用例 - 报纸和订阅者。一家报纸公司向订阅它的人发送报纸。它出版报纸,人们订阅它。

根据您的查询,这些订阅者可以订阅许多报纸。所以,它应该是多对多的。如果您考虑设计和开发的系统迎合所有订户和所有报纸,则似乎如此。那么这个订阅者-报纸世界是多对多的。你是对的。正如上面的评论中所讨论的那样 - Twitter 句柄有多个订阅者,他们订阅了多个 twitter 句柄。是多对多。

但是有一个问题。

实际上要回答您的问题-我们需要将发布者-订阅者之间的这种多对多关系分解为两部分-
1.从发布者到订阅者的一对多
2. 从订阅者到发布者的一对多

从出版商到订户的一对多一直被使用 - 报纸出版商向其订户分发报纸,推文出现在关注者提要中等。

但是,从订阅者到发布者的一对多关系真的有用吗?我的意思是以多人和他们订阅的 Twitter 句柄为例。假设一位订阅者发布了一些推文。此信息是否与他/她关注的推特句柄反向流动?不。推特用户知道他们的粉丝发了推文吗?不。
信息不会以相反的方向从订阅者流向发布者,或者从观察者流向主题。那么如果没有信息从观察者流向主题——为什么要为它设计!那就是你的答案。

关于oop - 为什么观察者设计模式通常被描绘成一对多?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/34630072/

相关文章:

design-patterns - 菱形符号在 UML 类图中表示什么?

swift - 使用观察者模式设置委托(delegate)时遇到问题

c++ - 具有不同通知的观察者模式

python - 设置属于某个类的类的最有效方法是什么

python-3.x - Python 设计模式 : Nested Abstract Classes

php - 在方法中声明 protected 变量

c++ - 设计模式中对象中过程(方法和操作)的状态

java - SQL 请求和循环结果最佳模式