定义

      观察者模式（Observer Pattern）属于行为型设计模式，作为一种经典的设计模式，它蕴含着一种类似“订阅”的机制。存在观察者和被观察者两种角色。

• 观察者：订阅消息，是被动接收消息的一方，接收到消息后可执行相应的操作。
• 被观察者：维护一个观察者列表，可增减观察者，当消息触发时发送给每一个在列表内的观察者。

被观察者和观察者是一个一对多的关系，观察者通过订阅消息，将状态存储在被观察者中，当消息事件触发时，被观察者会通知所有订阅的观察者，从而达到一个“监听”的效果。

其实从头到尾被观察者做了增删订阅列表、通知观察者大部分事情，观察者们只需要处理接收的消息即可。用较为通俗的语言来讲，被观察者也可以被称为发布者，观察者们也可以被叫做订阅者。（注意：观察者模式并不等同于发布订阅模式，两者并不是一回事。）

举例说明

       举个例子，一天蚁人、绿巨人、超人一起到商店购买能量饮料，但商店今天缺货。这可怎么办呢？绿巨人Hulk表示我们明天再来吧！可是如果明天还没货那岂不又白跑一趟，这是一个办法没错，但显然不是一个好办法。

       商店老板听到后表示自己有个好办法，商店老板说他看过我的文章，理解观察者模式的思想，于是主动提出自己扮演被观察者。建立一张需求清单（观察者列表），记录了三位客户想要的能量饮料，并且留下了三位的联系方式。

几天后，新的饮料到货了，商店老板查阅了一下需求清单，将到货消息编辑成短信群发给名单上的客户，名单上的所有客户收到消息后得知可以去商店购买了，于是有人听到消息立刻就去了，有人办完手上的事情才去，甚至有人等到日落才去。商店老板利用观察者模式合理解决了供需问题，生意兴隆蒸蒸日上。

代码实现

       这里设计一个接口IObserver用来作为观察者实现的约束，若想要成为观察者，必须实现IObserver接口并且必须要实现update方法。再设计了一个Store类，内部维护了一个观察者列表observers，拥有添加和通知方法。（这里简单实现，忽略观察者的移除方法）

对于客户端而言，分别需要常见被观察者和观察者实例，将所有观察者添加到被观察者维护的列表中。当使用被观察者实例去发布消息，所有添加在被观察者内部列表的所有观察者都可以接收到消息。

前端应用

       在前端应用中，观察者模式和类似的思想也十分常见。

• DOM事件注册：通过addEventlistener注册一个事件，比如注册click事件，当事件触发时会通知所有的回调函数。
• MutationObserver：通过监听DOM树的变化来抛出事件，当DOM树发生删减元素、属性变化等，会通知所有MutationObserver实例。
• IntersectionObserver：与MutationObserver类似，内部有适用于实现异步处理的方法。

总结

       观察者模式是一种经典的设计思想，可以将观察者和被观察者之间耦合的逻辑进行解耦，使职责更加清晰，提高了代码的可维护性。前端必须掌握的设计模式系列持续更新，如果对您有帮助希望多多点赞哦！