谁告诉你观察者就是发布订阅模式的！抽他！

来到心仪已久的公司面试，刚推开门还没等我说话HR 小姐姐就主动问我：你是来参加面试的吧？



我心想不对啊：难道是因为我长的帅，小姐姐一眼就看出来我将来是这栋楼的主人，所以才主动跟我打招呼。



我昂起头，略微点点头：是的。



HR小姐姐：面试官马上就过来，我先带你去会议室。



在去会议室的路上，我发现大家脖子上都带着亮闪闪的工牌，我下意识的看了看我的脖子上，除了昨天没有洗澡留下来的一点汗渍啥也没有。



原来是因为我没带工牌才认出我的，顿时我的脸滚烫滚烫的，我承认刚才我有点自恋了。



HR小姐姐：怎么了，你脸怎么红通通的，是不舒服吗？



我摸了摸脸：没有没有，面试有点紧张，害。



来到会议室，HR 小姐姐给我递过一杯水：面试官临时有个会，你稍微等一会。



我：好的。



我心里咕噜：怎么突然有个会，会不会是因为看了我的简历觉得我菜，故意找了一个借口，待会肯定让 HR 过来说面试太忙今天不面了。



果不其然，门开了，一位头发油油的满脸是痘的中年大叔向我走来。



我心想：这不会就是传说中的架构师吧。看来还是很看重我啊，第一面就派一个架构师来面我，我得好好表现一下。



架构师：你就是xxx 吧，刚才有个会议我来晚了，我们开始面试吧，一分钟简单介绍一下自己。



果然没有猜错，给我一分钟介绍，幸亏之前是按照一分钟准备的，我要开始背了。



我张嘴一笑，露出自信的大牙：尊敬的架构师你好，我是 xxx，之前在上一家公司担任……



架构师点点头：很好。我看你简历上写了很多技能，你挑一个你最熟悉的。



我有点凌乱了：架构师怎么不按套路出牌，应该会问我 HashMap 的源码，Java 锁的机制等。我想了想我比较熟悉的：Java 集合类、JVM、多线程、spring 全家桶，我如果说这些肯定会被架构师鄙视，差点忘了我还有一个杀手锏：设计模式。



我拍了拍胸脯：架构师你好，我之前参与项目重构用到了很多设计模式，要不你问我设计模式的东西吧。



架构师：那你说说观察者模式和发布订阅模式的区别？



我脑海立刻闪现《Head First设计模式》里面讲的：Publishers + Subscribers = Observer Pattern，问这么简单的问题难道是看不起我吗。



我内心无比激动，嘴角露出胜利者的微笑：亲爱的架构师，我之前看过一本书《Head First 设计模式》，这里面讲的观察者模式和发布订阅模式是等同关系的，它们是一回事。



架构师也笑了：不，它们不一样。



此刻我慌了，双手有点轻微颤抖，我哪里错了，它们明明是相等的。



架构师：我待会还有个会，要不今天的面试先到这里，你回家等消息吧。



回家后我心不甘，决定要把观察者模式和发布订阅模式搞清楚，通过一顿谷歌后我写了下面这些笔记：



观察者模式



观察者模式一般有观察者和被观察者。举个例子：大家在学校上自习的时候，等老师走了有些人会玩手机、吃零食、交头接耳找隔壁妹妹聊天，但是被老师发现可就不好了，所以大家想了一个招，让坐在最后排的同学帮忙“放风”，老师一来就给大家一个手势通知大家，大家就继续装好好学生（哈嘿）。



这其实就是一个典型的观察者模式，“放风”的同学是被观察者，玩手机、吃零食的同学是观察者，大家都在观察“放风”同学的手势，一旦老师来了，被观察者就会通知大家。



好了，让我们看看 UML 建模是如何定义的。



>观察者模式定义对象间一种一对多的依赖关系，使得每当一个对象改变状态，则所有依赖于它的对象都会得到通知并自动更新。



UML结构图如下：





Subject类是主题，它把所有对观察者对象的引用文件存在了一个集合里，每个主题都可以有任何数量的观察者。它是一个抽象主题，提供了一个可以增加和删除观察者对象的接口。



Observer类是抽象观察者，为所有的具体观察者定义一个接口，在得到主题的通知时更新自己。



ConcreteSubject类是具体主题，将有关状态存入具体观察者对象，在具体主题内部状态改变时，给所有登记过的观察者发出通知。



ConcreteObserver是具体观察者，实现抽象观察者角色所要求的更新接口，以便使本身的状态与主题的状态相协同。



发布订阅模式



举个生活中的例子，比如我们想要订阅一份国家地理杂志，一般需要我们先向邮局申请（付钱），告诉邮局我要订阅这份杂志，苦等数日杂志终于印刷好了，这个时候我们不会直接跑到印刷厂里去，而是等印刷厂将杂志送给邮局，然后邮局才会慢吞吞地将杂志送到家（推模式），如果你实在等不及了跑到邮局直接取杂志，恭喜你学会了“拉模式”。





用专业术语来解释发布订阅模式：



订阅者把自己想订阅的事件注册到调度中心，当该事件触发时候，发布者发布该事件到调度中心（顺带上下文），由调度中心统一调度订阅者注册到调度中心的处理代码。





在发布订阅模式里发布者并不会直接通知订阅者，换句话说发布者和订阅者彼此互不感知。



那发布者和订阅者如何交流呢？答案是通过中间的调度中心。



• 发布者将消息发送给调度中心，告诉它你帮我把消息放到 Topic1中。

• 订阅者告诉调度中心，我需要订阅 topic1，你帮我留意一下。

• 当有消息来了，订阅者可以采取拉模式或者推模式来获取消息。



有态度的总结



话不多说，先上一张图：



从表面上看：



• 观察者模式里只有两个角色：观察者和被观察者。

• 发布订阅模式里有三种角色：发布者、订阅者、调度器（第三者）。



往更深层次讲：



• 观察者和被观察者是松耦合的关系。

• 发布者和订阅者则完全不存在耦合。



从使用层面上讲：



• 观察者模式经常用于单个应用内部。

• 发布订阅模式更多是一种跨应用的模式(cross-application pattern)，比如我们常用的消息中间件Kafka 等。



综上：观察者模式和发布订阅模式本质上都有发布订阅的思想，但是又有一定的区别，所以我们不能将二者完全等同起来。