一、观察者模式
【1】定义
观察者模式定义了对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都将得到通知，并自动更新。观察者模式属于行为型模式，行为型模式关注的是对象之间的通讯，观察者模式就是观察者和被观察者之间的通讯。观察者模式有一个别名叫“发布-订阅模式”，或者说是“订阅-发布模式”，订阅者和订阅目标是联系在一起的，当订阅目标发生改变时，逐个通知订阅者。
【2】案例
案例：我办了一个补习班，学生想来我这学习，必须先报名（订阅）。收齐一帮学生，开始教学，学生们听了我的课及时更新了自己的认知。我和学生们紧密相连。每个人我都认识。我和学生就是上面文章开头所说的 "一对多" 的依赖关系。
【3】主要解决的问题
一个对象状态改变给其他对象通知的问题，而且要考虑到易用和低耦合，保证高度的协作。
【4】优点
- 观察者和被观察者是抽象耦合的。
- 建立一套触发机制。
【5】缺点
- 如果一个被观察者对象有很多的直接和间接的观察者的话，将所有的观察者都通知到会花费很多时间。
- 如果在观察者和观察目标之间有循环依赖的话，观察目标会触发它们之间进行循环调用，可能导致系统崩溃。
- 观察者模式没有相应的机制让观察者知道所观察的目标对象是怎么发生变化的，而仅仅只是知道观察目标发生了变化。
二、发布-订阅模式
【1】介绍
其实24种基本的设计模式中并没有发布-订阅模式，上面也说了，他只是观察者模式的一个别称。但是经过时间的沉淀，似乎他已经强大了起来，已经独立于观察者模式，成为另外一种不同的设计模式。在现在的发布订阅模式中，称为发布者的消息发送者不会将消息直接发送给订阅者，这意味着发布者和订阅者不知道彼此的存在。在发布者和订阅者之间存在第三个组件，称为消息代理或调度中心或中间件，它维持着发布者和订阅者之间的联系，过滤所有发布者传入的消息并相应地分发它们给订阅者。
【2】案例
线上课程：我在某视频网站上开了一个专栏，把我的课上传上去，喜欢的同学订阅我的专栏。后续我只要把最新课程传到视频站上就好了，学生们听了我的课亦能及时新了自己的认知。我和学生们的联系不是那么大了。我也不需要认识他们。
后者比前者多了一个类似中转站的东西（调度中心），省了我好多事。有学生不愿意学了 ，直接找调度中心退订就好了，不用找我说。我发布的新课程也由调度中心做广播，不用我自己再一个个通知，不会影响到我自己干其他工作。
【3】优点
- 支持简单的广播通信，当对象状态发生改变时，会自动通知已经订阅过的对象。
- 发布者与订阅者耦合性降低，发布者只管发布一条消息出去，它不关心这条消息如何被订阅者使用，同时，订阅者只监听发布者的事件名，只要发布者的事件名不变，它不管发布者如何改变
- 对于第一点，我们日常工作中也经常使用到，比如我们的ajax请求，请求有成功(success)和失败(error)的回调函数，我们可以订阅ajax的success和error事件。我们并不关心对象在异步运行的状态，我们只关心success的时候或者error的时候我们要做点我们自己的事情就可以了~
【4】缺点
- 创建订阅者需要消耗一定的时间和内存。
- 虽然可以弱化对象之间的联系，如果过度使用的话，反而使代码不好理解及代码不好维护等等。
【5】主要解决问题
发布-订阅模式是前端常用的一种设计模式，现在主流的MVVM框架，都大量使用了此设计模式，其主要作用有以下两点：
- 可以实现模块间通信
- 可以在一定程度上实现异步编程
前端的事件绑定有三要素：
- 传入事件类型
- 声明对应的回调方法
- 触发条件。触发条件为对应的事件类型。前端DOM的事件系统本质也是发布订阅模式，而我们在业务处理中所应有的模式也与此类似，只不过发布订阅模式应用的是自定义事件类型，可以自定义。
三、两者区别
订阅-发布是观察者模式的一个变种。
观察者模式中主体和观察者是互相感知的，发布-订阅模式是借助第三方来实现调度的，发布者和订阅者之间互不感知
订阅-发布，观察者只有订阅了才能接受到被观察者的消息，同时观察者还可以取消接受被观察者的消息，也就是说在观察者和被观察者之间存在-个经纪人Broker来管理观察者和被观察者。
从表面上看:
- 观察者模式里，只有两个角色一一 观察者+被观察者
- 而发布订阅模式里，却不仅仅只有发布者和订阅者两个角色，还有一个经常被我们忽略的一一经纪人Broker
往更深层次讲:
- 观察者和被观察者，是松耦合的关系
- 发布者和订阅者，则完全不存在耦合
从使用层面上讲
- 观察者模式，多用于单个应用内部
- 发布订阅模式，则更多的是一种跨应用的模式(cross-application pattern)，比如消息中间件
文章每周持续更新，可以微信搜索「 前端大集锦 」第一时间阅读，回复【视频】【书籍】领取200G视频资料和30本PDF书籍资料
