订阅发布者模式 观察者模式_观察者模式与发布-订阅模式

订阅发布者模式 观察者模式

重点 (Top highlight)

软件工程 ， 系统 (Software Engineering, Systems)

Don’t get confused with these two similar but different patterns, and know which one to use when.

不要将这两种相似但不同的模式弄混了，并知道何时使用哪种模式。

This difference is important to not just generic Software Engineers, but also to Data Engineers and is the basis for the understanding event-driven architectures for data pipelines.

这种差异不仅对通用软件工程师很重要，对于数据工程师也很重要，并且是理解事件驱动的数据管道体系结构的基础。

Let’s look at both of them individually, before we eventually list-out the differences.

在最终列出差异之前，让我们分别查看它们两个。

观察者模式 (Observer Pattern)

“The observer pattern is a software design pattern in which an object, called the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods.” — Wikipedia definition [1]

“ 观察者模式 是一种软件设计模式，其中一个对象，叫主题 ， 保持其家属 ，被称为 观察 名单 ，并通知他们自动的任何状态变化，通常是通过调用他们的方法之一。” —维基百科定义[1]

The observer pattern allows a given object (called the subject) to be monitored by a dynamic group of “observer” objects. Whenever a value on the subject changes, it lets all the observers object know that a change has occurred, by calling their methods update() (say) method. Each observer may be responsible for different tasks whenever the core object changes; the subject doesn’t know or care what those tasks are, and the observer doesn’t typically know or care what other observers are doing.

观察者模式允许 由动态的“观察者”对象组监视 给定的对象(称为 主题 )。 每当主题的值发生更改时，它都会 通过调用其方法 update() (say)方法 让所有 观察者 对象知道已发生更改 。 每当核心对象发生变化时，每个观察者可能负责不同的任务； 受试者不知道或不在乎这些任务是什么，观察者通常也不知道或不在乎其他观察者在做什么。

As an example, let’s create a SubjectMixin which we can mix-in in any Python class to make it easily adhere to the Subject of Observer Pattern.

作为示例，让我们创建一个SubjectMixin ，我们可以将其混入任何Python类中以使其轻松遵守观察者模式的Subject。

Screenshot of a piece of Author’s code 一段作者代码的屏幕截图

Similarly, let’s create a ObserverMixin which we can mix-in in any class to make it easily adhere to Object of Observer Pattern.

同样，让我们​​创建一个ObserverMixin ，我们可以将其混入任何类中以使其易于遵守Observer Pattern对象。

Screenshot of a piece of Author’s code 一段作者代码的屏幕截图

Further, let’s create a Subject named Data and two Observers named HexViewer and DecimalViewer.

此外，让我们创建一个名为Data的Subject和两个名为HexViewer和DecimalViewer 。

Screenshot of a piece of Author’s code 一段作者代码的屏幕截图

Finally, let’s see the observer pattern in action:

最后，让我们看看实际的观察者模式：

Screenshot of a piece of Author’s code 一段作者代码的屏幕截图

发布者-订阅(Pub-Sub)模式 (Publisher-Subscribe (Pub-Sub) Pattern)

The publisher-subscriber pattern can be considered as an improvized (asynchronous and loosely-coupled) version of the observer pattern. In the pub-sub pattern, senders of messages (called publishers) do not send messages directly to specific receivers (called subscribers). There is an intermediate component, called broker, (or message broker, event bus), to which data is sent by publisher and from where data is received by subscribers. It filters all incoming messages and distributes them accordingly. The popular methods of message filtering are topic-based and content-based.

的 发布者-订阅者模式 可以认为是 观察者模式的即兴(异步和松耦合)版本 。 在pub-sub模式中，消息的发送者(称为发布者)不直接将消息发送给特定的接收者(称为订阅者)。 有一个 中间成分 ，称为 经纪人 ，(或消息代理，事件总线)，发布者将数据发送到此，订阅者从那里接收数据。 它过滤所有传入的消息并进行相应的分发。 消息过滤的流行方法是 基于主题 和 基于内容 。

This means that the publisher and subscriber don’t know even about the existence of one another, and so are just loosely-coupled.

这意味着发布者和订阅者 甚至都不知道彼此的存在 ，因此只是松散耦合的。

You might like to check Data Streaming with Apache Kafka to appreciate the beauty of the pub-sub mechanism which helps you in making your architecture horizontally-scalable, fault-tolerant, and allows your data transportation at low-latencies.

您可能想检查Apache Kafka的数据流，以欣赏pub-sub机制的美妙之处，该机制有助于使您的体系结构可水平扩展，容错，并允许低延迟的数据传输。

观察者模式与发布-订阅模式之间的区别 (Difference between Observer and Pub-Sub Pattern)

We now understand what individually both of these patterns are. Let’s list their differences:

现在，我们了解了这两种模式分别是什么。 让我们列出它们的区别：

• In the observer pattern, the source of data itself (the Subject) knows who all are its observers. So, there is no intermediate broker between Subject and Observers. Whereas in pub-sub, the publishers and subscribers are loosely coupled, they are unaware of even the existence of each other. They simply communicate through a broker.
  在观察者模式中，数据源本身(主题)知道谁都是观察者。 因此，主题和观察者之间没有中间代理。 在pub-sub中，发布者和订阅者之间是松散耦合的，但他们甚至都不知道彼此的存在。 他们只是通过经纪人进行交流。
• Similar to what we could see in the previous example, the observer pattern is mostly implemented synchronously, i.e. the Subject calls the appropriate method of all its observers when an event occurs. Whereas, the pub-subs pattern is mostly implemented asynchronously (using a message queue), such as Apache Kafka.
  与我们在前面的示例中看到的类似，观察者模式主要是同步实现的，即，事件发生时，主题调用其所有观察者的适当方法。 而pub-subs模式主要是异步实现的(使用消息队列)，例如Apache Kafka。
• The observer pattern is generally implemented in a single-application scope. On the other hand, the publisher-subscriber pattern is mostly used as a cross-application pattern (such as how Kafka is used as Heart of event-driven architecture) and is generally used to decouple data/event streams and systems.
  观察者模式通常在单个应用程序范围内实现。 另一方面，发布者-订阅者模式通常用作跨应用程序模式(例如，如何将Kafka用作事件驱动体系结构的心脏)，并且通常用于解耦数据/事件流和系统。

翻译自: https://medium.com/towards-artificial-intelligence/observer-pattern-vs-pub-sub-pattern-7f467bcf5fe

订阅发布者模式 观察者模式