design-patterns - 推拉机制观察者模式

Question

目前我正在研究设计模式，但我对观察者模式是使用推机制还是使用拉机制感到困惑？

我已经阅读了这个的不同实现，并不能真正确定哪个是正确的。

另外，我想知道推模型对拉模型的三个直接优势。
我猜其中之一是推模型的耦合度低于拉模型？

Answer 1

观察者模式的细节(重点是提出的问题)

定义 :观察者模式定义了对象之间的一对多依赖关系，这样当一个对象改变状态时，它的所有依赖对象都会收到通知并自动更新

关注三件事 :

可观察对象 - 被观察的对象。

Observer objects - 观察可观察对象的对象

通信机制-拉或推机制

At the moment i'm studying design patterns and i've came to a part where i'm confused whether the observer pattern makes use of the push mechanism or does it makes use of the pull mechanism ?

混淆可能是因为您是按名称进行文学创作 - 拉或推。

请注意，在这两种机制中，通知所有订阅的观察者始终是 Observable 对象的责任，但区别在于是 [Push->] 观察者获得了它想要的确切数据还是 [Pull->] 获得了数据包裹在某个对象(主要是 Observable 对象)中，它必须从中提取所需的数据。

Push -> Observer 直接获取需要的数据

Pull -> Observer 获取包装在对象中的数据，它需要提取它。

I've read different implementations of this and can't really establish which one is correct.

这里不是修正的问题，实际上两者在任何情况下都可以正常工作。它只是最适合特定场景/情况，如果我们看到两种机制的以下详细信息，就可以轻松分析。

Also i'd like to know three straight forward advantages of the push model towards the pull model. I guess one of them is that the push model is less coupled then the pull model ?

我可能无法提供 3 个优势，但让我尝试一下，如果我可以通过用例示例让您清楚地了解在哪里使用什么:

插入机制

这纯粹是 Observable 的责任，Observer 只需要确保他们在更新方法中放置了所需的代码。

好处

“推”模型的主要优点是观察者和主体之间的耦合较低。

Observable 和 Observer 都是接口(interface)/抽象类，这实际上是一个设计原则 - 接口(interface)或父类(super class)型的程序

坏处

灵活性较低:由于 Observable 需要将所需的数据发送给观察者，如果我们有 1000 个观察者并且其中大多数需要不同类型的数据，那么它会变得困惑。

用例

当最多有 2-3 个不同类型的观察者(不同类型意味着观察者需要不同的数据)或所有观察者都需要相同类型的数据时，应该使用它。

就像银行的代币系统

在这种情况下，所有观察者(不同的 LED)只需要一个通知更新等待 token 编号的列表，因此与拉动机制相比，以这种方式实现可能更好。

拉动机制

在 pull 机制中，Observable 有责任通知所有观察者某些事情发生了变化，但是这次 Observable 共享发生变化的整个对象，有些观察者可能不需要完整的对象，所以观察者只需要提取所需的来自该完整项目的更新方法中的详细信息。

好处

这样做的好处是更加灵活。

每个观察者都可以自己决定要查询什么，而无需依赖主体发送正确(仅需要)的信息。

坏处

为了从共享的完整对象中查询正确的信息，观察者必须了解有关主题的信息。

用例

当有超过 2-3 个不同类型的观察者时应该使用它(不同类型意味着观察者需要不同的数据)

就像任何外汇汇率提供商为不同的投资银行发布外汇汇率一样

在这种情况下，有些银行只处理 INR，有些银行只处理 GBP 等，因此与 Push 机制相比，它应该使用 Pull 机制来实现。

引用文献

设计模式的第一本书籍

https://softwareengineering.stackexchange.com/questions/253398/the-observer-pattern-using-the-pulling-mechanism?newreg=999c28a6a1f6499783fbe56eb97fa8ec

https://dzone.com/articles/observer-pattern