摘要：觀察者模式與發(fā)布訂閱的區(qū)別在模式中，知道，同時還保留了的記錄。發(fā)布者訂閱者在大多情況下是異步方式使用消息隊列。圖片源于網(wǎng)絡(luò)侵權(quán)必刪如果以結(jié)構(gòu)來分辨模式，發(fā)布訂閱模式相比觀察者模式多了一個中間件訂閱器，所以發(fā)布訂閱模式是不同于觀察者模式的。

學(xué)習(xí)了一段時間設(shè)計模式，當(dāng)學(xué)到觀察者模式和發(fā)布訂閱模式的時候遇到了很大的問題，這兩個模式有點類似，有點傻傻分不清楚，博客起因如此，開始對觀察者和發(fā)布訂閱開始了Google之旅。對整個學(xué)習(xí)過程做一個簡單的記錄。

觀察者模式

當(dāng)對象間存在一對多關(guān)系時，則使用觀察者模式(Observer Pattern)。比如，當(dāng)一個對象被修改時，則會自動通知它的依賴對象。觀察者模式屬于行為型模式。在觀察模式中共存在兩個角色觀察者(Observer)與被觀察者(Subject)，然而觀察者模式在軟件設(shè)計中是一個對象，維護一個依賴列表，當(dāng)任何狀態(tài)發(fā)生改變自動通知它們。

其實觀察者模式是一個或多個觀察者對目標(biāo)的狀態(tài)感興趣，它們通過將自己依附在目標(biāo)對象之上以便注冊所感興趣的內(nèi)容。目標(biāo)狀態(tài)發(fā)生改變并且觀察者可能對這些改變感興趣，就會發(fā)送一個通知消息，調(diào)用每個觀察者的更新方法。當(dāng)觀察者不再對目標(biāo)狀態(tài)感興趣時，它們可以簡單的將自己從中分離。

在觀察者模式中一共分為這么幾個角色：

Subject:維護一系列觀察者，方便添加或刪除觀察者

Observer:為那些在目標(biāo)狀態(tài)發(fā)生改變時需要獲得通知的對象提供一個更新接口

ConcreteSuject:狀態(tài)發(fā)生改變時，想Observer發(fā)送通知，存儲ConcreteObserver的狀態(tài)

ConcreteObserver:具體的觀察者

舉例

舉一個生活中的例子，公司老板可以為下面的工作人員分配認為，如果老板作為被觀察者而存在，那么下面所屬的那些員工則就作為觀察者而存在，為工作人員分配的任務(wù)來通知下面的工作人員應(yīng)該去做哪些工作。

通過上面的例子可以對觀察者模式有一個簡單的認知，接下來結(jié)合下面的這張圖來再次分析一下上面的例子。

如果Subject = 老板的話，那么Observer N = 工作人員，如果細心觀察的話會發(fā)現(xiàn)下圖中莫名到的多了一個notify()，那么上述例子中的工作就是notify()。

圖片源于網(wǎng)絡(luò),侵權(quán)必刪

既然各個關(guān)系已經(jīng)屢清楚了，下面通過代碼來實現(xiàn)一下上述的例子：

//  觀察者隊列
class ObserverList{
    constructor(){
        this.observerList = {};
    }
    Add(obj,type = "any"){
        if(!this.observerList[type]){
            this.observerList[type] = [];
        }
        this.observerList[type].push(obj);
    }
    Count(type = "any"){
        return this.observerList[type].length;
    }
    Get(index,type = "any"){
        let len = this.observerList[type].length;
        if(index > -1 && index < len){
            return this.observerList[type][index]
        }
    }
    IndexOf(obj,startIndex,type = "any"){
        let i = startIndex,
            pointer = -1;
        let len = this.observerList[type].length;
        while(i < len){
            if(this.observerList[type][i] === obj){
                pointer = i;
            }
            i++;
        }
        return pointer;
    }
    RemoveIndexAt(index,type = "any"){
        let len = this.observerList[type].length;
        if(index === 0){
            this.observerList[type].shift();
        }
        else if(index === len-1){
            this.observerList[type].pop();
        }
        else{
            this.observerList[type].splice(index,1);
        }
    }
}
//  老板
class Boos {
    constructor(){
        this.observers = new ObserverList();
    }
    AddObserverList(observer,type){
        this.observers.Add(observer,type);
    }
    RemoveObserver(oberver,type){
        let i = this.observers.IndexOf(oberver,0,type);
        (i != -1) && this.observers.RemoveIndexAt(i,type);
    }
    Notify(type){
        let oberverCont = this.observers.Count(type);
        for(let i=0;i
代碼里面完全遵循了流程圖，Boos類作為被觀察者而存在，Staff作為觀察者，通過Work兩者做關(guān)聯(lián)。
如果相信的閱讀上述代碼的話可以出，其實觀察者的核心代碼就是peopleList這個對象，這個對象里面存放了N多個Array數(shù)組，通過run方法觸發(fā)觀察者的notify隊列。觀察者模式主要解決的問題就是，一個對象狀態(tài)改變給其他對象通知的問題，而且要考慮到易用和低耦合，保證高度的協(xié)作。當(dāng)我們在做程序設(shè)計的時候，當(dāng)一個目標(biāo)對象的狀態(tài)發(fā)生改變，所有的觀察者對象都將得到通知，進行廣播通知的時候，就可以使用觀察者模式啦。
優(yōu)點

觀察者和被觀察者是抽象耦合的。
建立一套觸發(fā)機制。

缺點

如果一個被觀察者對象有很多的直接和間接的觀察者的話，將所有的觀察者都通知到會花費很多時間。
如果在觀察者和觀察目標(biāo)之間有循環(huán)依賴的話，觀察目標(biāo)會觸發(fā)它們之間進行循環(huán)調(diào)用，可能導(dǎo)致系統(tǒng)崩潰。
觀察者模式?jīng)]有相應(yīng)的機制讓觀察者知道所觀察的目標(biāo)對象是怎么發(fā)生變化的，而僅僅只是知道觀察目標(biāo)發(fā)生了變化。

小結(jié)
對于觀察者模式在被觀察者中有一個用于存儲觀察者對象的list隊列，通過統(tǒng)一的方法觸發(fā)，目標(biāo)和觀察者是基類，目標(biāo)提供維護觀察者的一系列方法，觀察者提供更新接口。具體觀察者和具體目標(biāo)繼承各自的基類，然后具體觀察者把自己注冊到具體目標(biāo)里，在具體目標(biāo)發(fā)生變化時候，調(diào)度觀察者的更新方法。
發(fā)布/訂閱模式
在發(fā)布訂閱模式上卡了很久，但是廢了好長時間沒有搞明白，也不知道自己的疑問在哪，于是就瘋狂Google不斷地翻閱找到自己的疑問，個人覺得如果想要搞明白發(fā)布訂閱模式首先要搞明白誰是發(fā)布者，誰是訂閱者。
發(fā)布訂閱：在軟件架構(gòu)中，發(fā)布-訂閱是一種消息范式，消息的發(fā)送者（稱為發(fā)布者）不會將消息直接發(fā)送給特定的接收者（稱為訂閱者）。而是將發(fā)布的消息分為不同的類別，無需了解哪些訂閱者（如果有的話）可能存在。同樣的，訂閱者可以表達對一個或多個類別的興趣，只接收感興趣的消息，無需了解哪些發(fā)布者（如果有的話）存在。-- 維基百科
看了半天沒整明白(????)，慚愧...于是，學(xué)習(xí)的路途不能止步，繼續(xù)...
大概很多人都和我一樣，覺得發(fā)布訂閱模式里的Publisher，就是觀察者模式里的Subject，而Subscriber，就是Observer。Publisher變化時，就主動去通知Subscriber。其實并不是。在發(fā)布訂閱模式里，發(fā)布者，并不會直接通知訂閱者，換句話說，發(fā)布者和訂閱者，彼此互不相識。互不相識？那他們之間如何交流？
答案是，通過第三者，也就是在消息隊列里面，我們常說的經(jīng)紀人Broker。
發(fā)布者只需告訴Broker，我要發(fā)的消息，topic是AAA,訂閱者只需告訴Broker，我要訂閱topic是AAA的消息,于是，當(dāng)Broker收到發(fā)布者發(fā)過來消息，并且topic是AAA時，就會把消息推送給訂閱了topic是AAA的訂閱者。當(dāng)然也有可能是訂閱者自己過來拉取，看具體實現(xiàn)。
也就是說，發(fā)布訂閱模式里，發(fā)布者和訂閱者，不是松耦合，而是完全解耦的。

圖片源于網(wǎng)絡(luò),侵權(quán)必刪
通過上面的描述終于有了一些眉目，再舉一個生活中的例子，就拿微信公眾號來說，每次微信公眾號推送消息并不是一下子推送給微信的所有用戶，而是選擇性的推送給那些已經(jīng)訂閱了該公眾號的人。
老規(guī)矩吧，用代碼實現(xiàn)一下：
class Utils {
  constructor(){
    this.observerList = {};
  }
  Add(obj,type = "any"){
    if(!this.observerList[type]){
      this.observerList[type] = [];
    }
    this.observerList[type].push(obj);
  }
  Count(type = "any"){
    return this.observerList[type].length;
  }
  Get(index,type = "any"){
    let len = this.observerList[type].length;
    if(index > -1 && index < len){
      return this.observerList[type][index]
    }
  }
  IndexOf(obj,startIndex,type = "any"){
    let i = startIndex,
        pointer = -1;
    let len = this.observerList[type].length;
    while(i < len){
      if(this.observerList[type][i] === obj){
        pointer = i;
      }
      i++;
    }
    return pointer;
  }
}
//  訂閱者
class Subscribe  extends Utils {};
//  發(fā)布者
class Publish extends Utils {};
//  中轉(zhuǎn)站
class Broker {
  constructor(){
    this.publish = new Publish();
    this.subscribe = new Subscribe();
  }
  //  訂閱
  Subscribe(fn,key){
    this.subscribe.Add(fn,key);
  }
  //  發(fā)布
  Release(fn,key){
    this.publish.Add(fn,key);
  }
  Run(key = "any"){
    let publishList = this.publish.observerList;
    let subscribeList = this.subscribe.observerList;
    if(!publishList[key] || !subscribeList[key]) throw "No subscribers or published messages";
    let pub = publishList[key];
    let sub = subscribeList[key];
    let arr = [...pub,...sub];
    while(arr.length){
      let item = arr.shift();
      item(key);
    }
  }
}
class Employees {
  constructor(name){
    this.name = name;
  }
  getName(){
    let {name} = this;
    return name;
  }
  receivedMessage(key,name){
    console.log(`${name}收到了${key}發(fā)來的消息`);
  }
}
class Public {
  constructor(name){
    this.name = name;
  }
  getName(){
    let {name} = this;
    return name;
  }
  sendMessage(key){
    console.log(`${key}發(fā)送了一條消息`);
  }
}
let broker = new Broker();
let SundayPublic = new Public("Sunday");
let MayPublic = new Public("May");
let Angie = new Employees("Angie");
let Aaron = new Employees("Aaron");
broker.Subscribe(() => {
  Angie.receivedMessage(SundayPublic.getName(),Angie.getName());
},SundayPublic.getName());
broker.Subscribe(() => {
  Angie.receivedMessage(SundayPublic.getName(),Aaron.getName());
},SundayPublic.getName());
broker.Subscribe(() => {
  Aaron.receivedMessage(MayPublic.getName(),Aaron.getName());
},MayPublic.getName());
broker.Release(MayPublic.sendMessage,MayPublic.getName());
broker.Release(SundayPublic.sendMessage,SundayPublic.getName());
broker.Run(SundayPublic.getName());
broker.Run(MayPublic.getName());
//  Sunday發(fā)送了一條消息
//  Angie收到了Sunday發(fā)來的消息
//  Aaron收到了Sunday發(fā)來的消息
//  May發(fā)送了一條消息
//  Aaron收到了May發(fā)來的消息
通過上面的輸出結(jié)果可以得出，只要訂閱過該公眾號的用戶，只要公眾號發(fā)送一條消息，所有訂閱過該條消息的用戶都是可以收到這條消息。雖然代碼有點多，但是確確實實能夠體現(xiàn)發(fā)布訂閱模式的魅力，很不錯。
優(yōu)點

支持簡單的廣播通信，當(dāng)對象狀態(tài)發(fā)生改變時，會自動通知已經(jīng)訂閱過的對象。
發(fā)布者與訂閱者耦合性降低，發(fā)布者只管發(fā)布一條消息出去，它不關(guān)心這條消息如何被訂閱者使用，同時，訂閱者只監(jiān)聽發(fā)布者的事件名，只要發(fā)布者的事件名不變，它不管發(fā)布者如何改變；同理賣家（發(fā)布者）它只需要將鞋子來貨的這件事告訴訂閱者(買家)，他不管買家到底買還是不買，還是買其他賣家的。只要鞋子到貨了就通知訂閱者即可。

缺點

創(chuàng)建訂閱者需要消耗一定的時間和內(nèi)存。
雖然可以弱化對象之間的聯(lián)系，如果過度使用的話，反而使代碼不好理解及代碼不好維護。

小結(jié)
發(fā)布訂閱模式可以降低發(fā)布者與訂閱者之間的耦合程度，兩者之間從來不關(guān)系你是誰，你要作什么？訂閱者只需要跟隨發(fā)布者，若發(fā)布者發(fā)生變化就會通知訂閱者應(yīng)該也做出相對于的變化。發(fā)布者與訂閱者之間不存在直接通信，他們所有的一切事情都是通過中介者相互通信，它過濾所有傳入的消息并相應(yīng)地分發(fā)它們。發(fā)布訂閱模式可用于在不同系統(tǒng)組件之間傳遞消息的模式，而這些組件不知道關(guān)于彼此身份的任何信息。
觀察者模式與發(fā)布訂閱的區(qū)別

在Observer模式中，Observers知道Subject，同時Subject還保留了Observers的記錄。然而，在發(fā)布者/訂閱者中，發(fā)布者和訂閱者不需要彼此了解。他們只是在消息隊列或代理的幫助下進行通信。
在Publisher / Subscriber模式中，組件是松散耦合的，而不是Observer模式。
觀察者模式主要以同步方式實現(xiàn)，即當(dāng)某些事件發(fā)生時，Subject調(diào)用其所有觀察者的適當(dāng)方法。發(fā)布者/訂閱者在大多情況下是異步方式（使用消息隊列）。
觀察者模式需要在單個應(yīng)用程序地址空間中實現(xiàn)。另一方面，發(fā)布者/訂閱者模式更像是跨應(yīng)用程序模式。


圖片源于網(wǎng)絡(luò),侵權(quán)必刪
如果以結(jié)構(gòu)來分辨模式，發(fā)布訂閱模式相比觀察者模式多了一個中間件訂閱器，所以發(fā)布訂閱模式是不同于觀察者模式的。如果以意圖來分辨模式，他們都是實現(xiàn)了對象間的一種一對多的依賴關(guān)系，當(dāng)一個對象的狀態(tài)發(fā)生改變時，所有依賴于它的對象都將得到通知，并自動更新，那么他們就是同一種模式，發(fā)布訂閱模式是在觀察者模式的基礎(chǔ)上做的優(yōu)化升級。在觀察者模式中，觀察者需要直接訂閱目標(biāo)事件。在目標(biāo)發(fā)出內(nèi)容改變的事件后，直接接收事件并作出響應(yīng)。發(fā)布訂閱模式相比觀察者模式多了個事件通道，訂閱者和發(fā)布者不是直接關(guān)聯(lián)的。目標(biāo)和觀察者是直接聯(lián)系在一起的。觀察者把自身添加到了目標(biāo)對象中，可見和發(fā)布訂閱模式差別還是很大的。在這種模式下，目標(biāo)更像一個發(fā)布者，他讓添加進來的所有觀察者都執(zhí)行了傳入的函數(shù)，而觀察者就像一個訂閱者。雖然兩種模式都存在訂閱者和發(fā)布者（具體觀察者可認為是訂閱者、具體目標(biāo)可認為是發(fā)布者），但是觀察者模式是由具體目標(biāo)調(diào)度的，而發(fā)布/訂閱模式是統(tǒng)一由調(diào)度中心調(diào)的，所以觀察者模式的訂閱者與發(fā)布者之間是存在依賴的，而發(fā)布/訂閱模式則不會。
總結(jié)
雖然在學(xué)習(xí)這兩種模式的時候有很多的坎坷，最終還是按照自己的理解寫出來了兩個案例?；蛟S理解的有偏差，如果哪里有問題，希望大家在下面留言指正，我會盡快做出修復(fù)的。
如果你和我一樣喜歡前端的話，可以加Qq群：135170291，期待大家的加入。