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

        我曾经在一次面试中被问到，“观察者模式和发布订阅模式有什么区别？” 我立即指出Pub-Sub意味着 Publisher-Subscriber，并且从书本"Head first Design Psttern"中生动的回忆到：

Publishers + Subscribers = Observer Pattern

“我知道了，这点小把戏可骗不了我。” 我想到。

我回答到他们是相同的，并且伴随着胜利者的微笑。

但是面试官也笑着答道，“不，他们不同”。

所以，我到底错过了什么？到底是哪里出错了？在我回家之后，我决定通过Google去找答案。这里我贴出来我查询到的文章摘录。

在我们专研他们的不同之前，让我们来谈一点点观察者模式和发布-订阅模式吧。

观察者模式：

观察者模式是所有设计模式中最简单的几种设计模式之一。我相信很多人会同意我的观点。不像很多其他的设计模式，你至少可以感受到它的主要概念，当你第一次读到观察者模式的时候。

观察者模式是一种软件设计模式，其中有一个被叫做订阅者的对象，维护着一个被称为观察者的列表，当有任何状态的变化时，会自动的通知他们。这种变化通常来自于对他们其中一种方法的调用。

看吧，即使在维基百科的定义中也不是特别难，对吧？如果你仍然很困惑，让我们解释的更通俗一些。

让我们假定你作为一名软件工程师正在找寻一份工作，并且你对“香蕉公司”非常感兴趣。所以你联系他们的招聘经理并且给了他们你的联系电话。他向你确保如果有任何的职位空缺，他会保证让你知道。并且还有其他几个候选人和你一样对这个职位感兴趣。当职位有空缺的时候，他们将会让所有的候选人知道。如果你进行了回应，他们将会安排一个面试。这样一个场景和观察者设计模式有什么关系呢？在这里，香蕉公司就是这个Subject ，它维持所有观察者（和你一样的候选人）列表并且通知所有观察者一个确定的事件——“职位空缺”。是不是很容易，伙计？

    

观察者设计模式（鸟瞰图）

当你曾经需要在一些软件或者应用中需要实现这样一种场景，你可以使用这个流程并且说你已经实现了观察者设计模式。（我不会在我的文章中展示任何代码而让我的文章变的臃肿，因为在英特网上有许多可以使用的例程）

发布订阅设计模式：

在观察者模式中，Subject 就像一个发布者一样，观察者完全和订阅者相关。Subject通知观察者就好像一个发布者通知他的订阅者一样。这就是为什么设计模式的书本或者文章使用发布订阅的概念去解释观察者设计模式。他的概念和观察者模式非常像。在真正的发布订阅模式和观察者模式之间的不同是：

在发布订阅模式中，发布者，即消息的发送者，不会对消息进行处理，直接将消息发送到特定的接收者，订阅者手中。

这就意味着订阅者和发布者不知道彼此的存在。有另外一个组件，叫做 broker 或者消息 broker 或者消息总线。发布者和订阅者都知道这个broker。这个broker会过滤所有收到的消息并且对消息进行分发。换句话说，发布订阅模式在不同的系统组件之间进行消息通信，这些组件不需要知道彼此的ID信息。Broker是如何过滤所有消息的呢？事实上，消息过滤有好几个过程。最主流的方法是，基于主题和基于内容。好吧，不会在这条路上走的更远，如果你感兴趣，维基百科是这样解释的

 简而言之，这两种设计模式的主要区别如下图所示：

 让我们快速总结一下区别：

在观察者模式中，观察者是有意识到Subject的，并且在Subject中维护着观察者的记录。然而在发布订阅模式中，发布者和订阅者不需要相互知道，他们仅仅是借助消息队列或者Broker进行通信。

在发布订阅模式中，和观察者模式相反，组件是松散耦合的。

观察者模式几乎是以同步的方式实现。当事件发生的时候，Subject调用它所有观察者的方法。发布订阅模式通过消息队列以异步的方式实现。

观察者模式需要在单应用地址空间中实现。在另一方面，发布订阅模式更多的是跨应用模式。

尽管这些设计模式有这些区别，一些人可能会说发布订阅模式是观察者的一个变种，因为他们之间的概念非常相似，而且这一点也没错。不需要去扣这些差异。他们很相似，不是吗？

希望你明白了，感谢阅读这篇文章。

如果有任何错误或者需要修改的地方，请让我知道。

致谢。

Observer vs Pub-Sub pattern | HackerNoon