面試官:能用JS寫一個發布訂閱模式嗎?
- 2021 年 11 月 3 日
- 筆記
- javascript, 前端開發, 前端面試, 設計模式
什麼是發布訂閱模式?能手寫實現一下嗎?它和觀察者模式有區別嗎?…
1 場景引入
我們先來看這麼一個場景:
假設現在有一個社交平台,平台上有一個大V叫Nami
Nami很牛,多才多藝,目前她有2個技能:會寫歌、會拍影片
她會把這些作品發布到平台上。關注她的粉絲就會接收到這些內容
現在他已經有3個粉絲了,分別是:Luffy、Zoro、Sanji
每次只要Nami一發布作品,3個粉絲的帳號上收到的消息就會更新
現在用程式碼來表示:
const luffy = {
update: function (songs, videos) {
console.log(songs, videos);
},
};
const zoro = {
update: function (songs, videos) {
console.log(songs, videos);
},
};
const sanji = {
update: function (songs, videos) {
console.log(songs, videos);
},
};
const nami = {
// 只要Nami的作品一更新,這個方法就會被調用
workUpdate: function () {
// 獲取作品
const songs = this.getSongs();
const videos = this.getVideos();
// 帳號更新
luffy.update(songs, videos);
zoro.update(songs, videos);
sanji.update(songs, videos);
},
getSongs: function () {
return "mp3";
},
getVideos: function () {
return "mp4";
},
};
現在問題來了
- 如果Nami又收穫了一個粉絲Robin,我既要添加一個robin對象,又要修改
workUpdate
方法 - 如果Nami又有了一項新技能:寫小說,我既要修改
workUpdate
函數,又要修改每個粉絲對象中的update
方法,因為參數增加了一個
發現問題沒有?
粉絲對象和大V對象之間的耦合度太高,導致兩者很難各自擴展
2 程式碼優化
2.1 解決增加粉絲問題
先來解決上述第1個問題,使得增加粉絲的時候不用再修改workUpdate
方法
首先,我們將「大V」抽象成一個類Star
,用數組fans
來保存粉絲列表,並新增一個添加粉絲的方法addFans
class Star {
constructor() {
this.fans = [];
}
addFans(fan) {
this.fans.push(fan)
}
workUpdate() {
const songs = this.getSongs();
const videos = this.getVideos();
this.fans.forEach((item) => item.update(songs, videos));
}
getSongs() {
return "MP3";
}
getVideos() {
return "MP4";
}
}
接著,將「粉絲」也抽象成一個類Fan
,我們在創建粉絲對象的時候傳入「大V」對象,調用該大V的addFans
方法來添加到粉絲列表
class Fan {
constructor(name, star) {
this.name = name
this.star = star
this.star.addFans(this)
}
update(songs, videos) {
console.log(songs, videos);
}
}
現在我們添加粉絲就不必再更改程式碼了
const nami = new Star()
const luffy = new Fan("luffy", nami);
const zoro = new Fan("zoro", nami);
const sanji = new Fan("sanji", nami);
const robin = new Fan("robin", nami);
nami.workUpdate()
2.2 解決添加作品問題
我們新增一個works
數組來保存大V的作品,並且為其添加get
和set
方法
class Star {
constructor() {
this.fans = [];
this.works = [];
}
addFans(fan) {
this.fans.push(fan);
}
setWorks(work) {
this.works.push(work);
// 添加作品後,調用更新方法
this.workUpdate();
}
getWorks() {
return this.works;
}
workUpdate() {
this.fans.forEach((item) => item.update());
}
}
對類Fan
進行相應修改:
class Fan {
constructor(name, star) {
this.name = name
this.star = star
this.star.addFans(this)
}
update() {
console.log(`${this.name}:${this.star.getWorks()}`)
}
}
現在大V添加作品就不必再更改程式碼了:
const nami = new Star();
nami.setWorks('song')
nami.setWorks('video')
nami.setWorks('novel')
const luffy = new Fan("luffy", nami);
const zoro = new Fan("zoro", nami);
const sanji = new Fan("sanji", nami);
nami.workUpdate();
3 觀察者模式
可以看到,在上述例子中,一個nami
對象和多個粉絲對象之間存在著一種一對多的依賴關係,當nami
對象有作品更新的時候,所有關注她的粉絲對象都會收到通知。
事實上,這就是觀察者模式
觀察者模式:定義對象間的一種一對多的依賴關係,當一個對象的狀態發生改變時,所有依賴於它的對象都得到通知並被自動更新
我們將2.2
中的程式碼進行進一步的抽象:
將「粉絲」看作觀察者(Observer),將「大V」看作被觀察的對象,稱為主題(Subject)
Subject
維護一個觀察者列表observerList
(原fans
數組)。當Subject
的狀態發生變化(原作品更新)時,通過調用notify
(原workUpdate
)方法通知所有觀察者,執行它們的update
方法
具體程式碼如下:
// 被觀察者:主題
class Subject {
constructor() {
this.observerList = [];
// 代表主題狀態
this.state = 0;
}
addObserver(observer) {
this.observerList.push(observer);
}
// 更改主題狀態
setState(state) {
this.state = state;
// 狀態改變後,通知所有觀察者
this.notify();
}
getState() {
return this.state;
}
notify() {
this.observerList.forEach((observer) => observer.update());
}
}
// 觀察者
class Observer {
constructor(name, subject) {
this.name = name;
this.subject = subject;
this.subject.addObserver(this);
}
update() {
console.log(`${this.name}:${this.subject.state}`);
}
}
4 經紀人登場
由於大V業務繁忙,所以他們需要經紀人來維持藝人與粉絲的聯繫
經紀人的工作包括:
- 維護大V的粉絲,經紀人手中會有一個粉絲名單
- 大V的新作品會交給經紀人,經紀人則負責把新作品發送給粉絲名單中的粉絲
抽象成一個類,如下:
class Manager {
constructor() {
this.fans = [];
this.works = [];
}
addFans(fan) {
this.fans.push(fan);
}
setWorks(work) {
this.works.push(work);
// 添加作品後,調用更新方法
this.workUpdate();
}
getWorks() {
return this.works;
}
workUpdate() {
this.fans.forEach((item) => item.update());
}
}
嗯?這段程式碼貌似在哪兒見過?
沒錯,和2.2
的Star
類一模一樣,只不過把類名改了改。
那這麼做有意義嗎?
事實上,程式碼一模一樣是因為在2.2
的Star
類中我們只寫了有關發布(即發布作品)和訂閱(即維護粉絲列表)的功能;而Star
類本身可能不止這個工作,比如創作內容。
現在我們將Star
類中的發布和訂閱的工作抽離出來,交給Manager
全權負責。而Star
類只要在創作完成後把作品交給Manager
就可以了
另一方面,粉絲Fan
也不再直接和Star
發生交互了,Fan
只關心能不能收到作品,所以Fan
直接和Manager
發生交互,Fan
去訂閱(這個行為相當於在Manager
維護的粉絲列表中添加粉絲)Manager
並從Manager
那兒獲取想要的作品
於是Star
和Fan
的程式碼如下:
class Star {
constructor() {}
// 創作
create(manager) {
// 將創作的new work交給經紀人
manager.setWorks("new work");
}
}
class Fan {
constructor(name, manager) {
this.name = name;
this.manager = manager;
this.manager.addFans(this);
}
update() {
console.log(`${this.name}:${this.manager.getWorks()}`);
}
}
5 發布訂閱模式
前面我們用了經紀人來負責發布和訂閱的工作,而不讓Star
和Fan
發生直接交互,達到了兩者解耦的效果
這就是發布訂閱模式
我們將4
中的Manager
進行進一步的抽象:
將「粉絲」看作訂閱者(Subscriber);將「大V」看作內容的發布者,在發布訂閱模式中稱為發布者(Publisher);把「經紀人」看作發布訂閱中心(或者說中間人Broker)
具體程式碼如下:
// 發布訂閱調度中心
class Broker {
constructor() {
this.subscribers = [];
// 代表主題狀態
this.state = 0;
}
// 訂閱
subscribe(subscriber) {
this.subscribers.push(subscriber);
}
// 更改主題狀態
setState(state) {
this.state = state;
// 狀態改變後,發布
this.publish();
}
getState() {
return this.state;
}
// 發布
publish() {
this.subscribers.forEach((subscriber) => subscriber.update());
}
}
// 發布者
class Publisher {
constructor() {}
changeState(broker, state) {
broker.setState(state);
}
}
class Subscriber {
constructor(name, broker) {
this.name = name;
this.broker = broker;
this.broker.subscribe(this);
}
update() {
console.log(`${this.name}:${this.broker.getState()}`);
}
}
來運行一下看看效果:
// 創建調度中心
const broker = new Broker()
// 創建發布者
const publisher = new Publisher()
// 創建訂閱者
const subscribe1 = new Subscriber('s1', broker)
const subscribe2 = new Subscriber('s2', broker)
const subscribe3 = new Subscriber('s3', broker)
// 發布者改變狀態並通知調度中心,調度中心就會通知各個訂閱者
publisher.changeState(broker, 1)
6 觀察者模式和發布訂閱模式的對比
從角色數量看
- 觀察者模式只有兩個角色:觀察者和被觀察者
- 發布訂閱模式有三個角色:發布者、訂閱者以及中間人(發布訂閱中心)
從耦合程度看
- 觀察者模式處於一種松耦合的狀態,即兩者依然有交互,但是又很容易各自擴展且不相互影響
- 發布訂閱模式中的發布者和訂閱者則完全不存在耦合,達到了對象之間解耦的效果
從意圖來看
- 兩者都:實現了對象間的一種一對多的依賴關係,當一個對象的狀態發生改變時,所有依賴於它的對象都將得到通知並自動更新
公眾號【前端嘛】