一、观察者模式
观察者模式在前端工程中是很常见的设计模式，因为前端交互中充斥着大量多控件联动的交互，当参与联动的组件数量比较多或者组件数量可能变化的时候，代码就会变得难以维护。但是如果我们写代码时遵循了观察者模式的设计，便可以较好的解决以上两个痛点。
观察者模式，指的是一个主题对象（subject），维护了一个依赖它的观察者（observers）数组，当subject变化的时候，会通知数组中的观察者自动更新它自己。
1. 定义
2. 现实举例
通过对观察者模式的定义的理解，我们不难在生活中找到对应的例子。比如：
- 定闹钟。相信小伙伴肯定有被闹钟叫醒的经历，我们定下了
8:00 AM的闹钟，这个闹钟的意义是叫我们起床工作，定完闹钟我们就可以放心睡觉了，因为时间到了之后，闹钟会通知我们的。 - 上课铃。我们知道上课铃响了之后要回到教室上课，所以上课铃是
subject，学生和老师都是observer，时间点相当于是上课铃的状态，当状态改变为指定状态的时候，就会执行notify。
错误举例：
- 红绿灯。虽然行人车辆都是红绿灯的观察者，但是红绿灯变了之后并没有主动通知观察者，而是观察者持续关注红绿灯的状态，这里少了一个
notify的过程，所以并不符合观察者模式。
3. 个人理解
在我看来观察者模式的重点是对observer的管理，subject状态更新的时候无需亲自找到每个observer去通知，对subject而言，只需要按下一个按钮，所有的observer就被全部通知到。举个例子：
// 不使用观察者模式
class Subject {
onchange() {
this.notify();
}
notify() {
observerA.update();
observerB.update();
observerC.update();
// such as above
}
}
// 使用观察者模式
class Subject {
constructor() {
this.observerList = [];
}
addObserver(obj) {
this.observerList.push(obj);
return this.observerList.length - 1;
}
removeObserver(token) {
this.observerList[token] = null;
}
onchange() {
this.notify();
}
notify() {
this.observerList.forEach(observer => {
observer && observer.update && observer.update();
});
}
}
const subject = new Subject();
subject.add(observerA);
subject.add(observerB);
subject.add(observerC);
现在看上去，使用观察者模式好像更复杂了，因为我们写了更多的代码，其实不然。假设现在我们的需求变了，假设依赖subject的对象变多了，如果我们没有使用观察者模式，那我们需要：（1）直接去修改notify方法；（2）保证每一个observer必须在当前执行上下文是可引用的，因为我们要直接把它们写到notify中。但是如果是使用了观察者模式，我们只需要调用subject.add就可以将依赖收集，而代码不要做任何改动。由此可见使用观察者模式会方便很多。
二、发布订阅“模式”
现在网络上有很多观点，有说发布订阅是一种独立的设计模式，也有说发布订阅就是观察者模式，在维基百科上没有搜索到“发布订阅模式”，因为维基百科上说明了发布订阅是一种消息范式。但是我的老板给我讲了一种观点我非常赞同：发布订阅并非一种设计模式，因为设计模式是原子性的，是不可能再拆分的，而发布订阅很明显是观察者模式和中介者模式组合而来的，可以说发布订阅是观察者模式和中介者模式的组合实现。仔细想想确实如此~。
1. 定义
下面是摘自维基百科对发布订阅的定义：
发布-订阅是一种消息范式，消息的发送者（publisher）不会将消息直接发送给特定的接收者（subcriber）。而是将发布的消息分为不同的类别，无需了解哪些订阅者（如果有的话）可能存在。同样的，订阅者可以表达对一个或多个类别的兴趣，只接收感兴趣的消息，无需了解哪些发布者（如果有的话）存在。
2. 现实举例
- 买房。我向中介表示我对
100w-昌平的房子和100w-石景山的房子以及500w-海淀的房子感兴趣，我不需要管有没有这样的房源，我只需要表达我的意愿，业主有卖房意愿后会给中介发布消息，然后中介会通知自己手里所有对该房源感兴趣的客户。
3. 个人理解
如果观察者模式体现的好处是将对observer管理的复杂度降到了O(1)，那么发布/订阅则是双向的，将subscriber和publisher的管理的复杂度都降到了O(1)。因为publisher只管发布topic，不管有谁依赖这个topic，而subscriber也只管订阅topic而不用操心有没有这个topic。这种模式在前端工程中也很常见，并且非常好用。下面我们简单实现下：
class Channel {
constructor() {
this.eventsMap = {};
}
subscribe(topic, obj) {
if (this.eventsMap[topic] === undefined) {
this.eventsMap[topic] = [];
}
this.eventsMap[topic].push(obj);
return this.eventsMap[topic].length - 1;
}
unsubscribe(topic, token) {
if (this.eventsMap[topic]) {
this.eventsMap[topic][token] = null;
}
}
publish(topic, ...args) {
const arr = this.eventsMap[topic];
if (arr instanceof Array) {
arr.forEach(subscriber => {
subscriber && subscriber['on' + topic] &&subscriber['on' + topic](...args);
})
}
}
}
const channel = new Channel;
let subscriberA, subscriberB; // 订阅者
channel.subscribe('start', subscriberA);
channel.subscribe('start', subscriberB);
channel.publish('start', Date.now());
三、观察者和发布订阅的区别
- 组成成员不同。观察者由两类对象组成，而发布订阅需要第三者参与。
- 交互对象不同。观察者模式是观察者和主题直接交互，而发布订阅的发布者和订阅者都只和中介交互。
- 发布订阅耦合程度更低，将发布者和订阅者完全解耦，双方都不知道对方的存在，而观察者模式下，观察者是知道主题的存在的。
