面試官：能用JS寫一個發布訂閱模式嗎？

• 1 場景引入
• 2 代碼優化
  • 2.1 解決增加粉絲問題
  • 2.2 解決添加作品問題
• 3 觀察者模式
• 4 經紀人登場
• 5 發布訂閱模式
• 6 觀察者模式和發布訂閱模式的對比

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";
  },
};

現在問題來了

1. 如果Nami又識訓了一個粉絲Robin，我既要添加一個robin物件，又要修改workUpdate方法
2. 如果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業務繁忙，所以他們需要經紀人來維持藝人與粉絲的聯系

經紀人的作業包括：

1. 維護大V的粉絲，經紀人手中會有一個粉絲名單
2. 大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 觀察者模式和發布訂閱模式的對比

從角色數量看

• 觀察者模式只有兩個角色：觀察者和被觀察者
• 發布訂閱模式有三個角色：發布者、訂閱者以及中間人（發布訂閱中心）

從耦合程度看

• 觀察者模式處于一種松耦合的狀態，即兩者依然有互動，但是又很容易各自擴展且不相互影響
• 發布訂閱模式中的發布者和訂閱者則完全不存在耦合，達到了物件之間解耦的效果

從意圖來看

• 兩者都：實作了物件間的一種一對多的依賴關系，當一個物件的狀態發生改變時，所有依賴于它的物件都將得到通知并自動更新

公眾號【前端嘛】

標籤：JavaScript

上一篇：Web前端學習教程，JavaScript小白入門的不二之選

下一篇：Web前端學習教程，JavaScript小白入門的不二之選