摘要：發(fā)布訂閱模式又叫觀察者模式，它定義對(duì)象間的一種一對(duì)多的依賴關(guān)系。事件觀察者模式應(yīng)該是最常用的模式之一。總之，當(dāng)消息一發(fā)布，所有的訂閱者都會(huì)收到消息。發(fā)布訂閱模式還可以用來(lái)幫助實(shí)現(xiàn)一些別的設(shè)計(jì)模式，比如中介者模式。

發(fā)布/訂閱模式又叫觀察者模式，它定義對(duì)象間的一種一對(duì)多的依賴關(guān)系。當(dāng)一個(gè)對(duì)象的狀態(tài)（發(fā)布者）發(fā)生改變時(shí)，所有依賴于它的對(duì)象都將得到通知。在 JavaScript 開(kāi)發(fā)中，我們一般用事件模型來(lái)替代傳統(tǒng)的發(fā)布—訂閱模式。

觀察者模式應(yīng)該是最常用的模式之一。在很多語(yǔ)言里都得到大量應(yīng)用。包括我們平時(shí)接觸的dom事件，也是js和dom之間實(shí)現(xiàn)的一種觀察者模式。

    document.body.addEventListener("click",function () {
        alert(111);
    },false);
    document.body.addEventListener("click",function () {
        alert(222);
    },false);
    document.body.addEventListener("click",function () {
        alert(333);
    },false);
    document.body.click();//模擬點(diǎn)擊事件

這里我們訂閱了document.body 的 click 事件，當(dāng) body 被點(diǎn)擊的時(shí)候，他就向訂閱者發(fā)布這個(gè)消息，順序彈出111 222 333。我們也可以隨意的增加和刪除訂閱者。總之，當(dāng)消息一發(fā)布，所有的訂閱者都會(huì)收到消息。

這里，手動(dòng)觸發(fā)事件直接用了document.body.click()；但是更好的做法是IE下用 fireEvent，標(biāo)準(zhǔn)瀏覽器下用 dispatchEvent。

發(fā)布/訂閱模式可以用一個(gè)全局的 Event 對(duì)象來(lái)實(shí)現(xiàn),訂閱者不需要了解消息來(lái)自哪個(gè)發(fā)布者，發(fā)布者也不知道消息會(huì)推送給哪些訂閱者，Event 作為一個(gè)類似“中介者” 的角色，把訂閱者和發(fā)布者聯(lián)系起來(lái)。

let Event = (function () {
    let clientList = {};
    let listen;
    let trigger;
    let remove;

    listen = function (name, cb) {
        if( !clientList[name] ) {
            clientList[name] = [];
        }
        clientList[name].push(cb);
    };

    trigger = function () {
        let name = [].shift.call(arguments);
        let fns = clientList[name];
        if( !fns || fns.length == 0 ) return false;
        fns.map((item, index) => {
            item(...arguments); // 不要直接將arguments傳入
        })
    };

    remove = function (name, cb) {
        let fns = clientList[name];
        if( !fns ) return false; // name對(duì)應(yīng)的消息么有被人訂閱
        if( !cb ) { // 沒(méi)有傳入cb(具體的回調(diào)函數(shù)), 表示取消 name 對(duì)應(yīng)的所有訂閱 
            fns && (fns.length = 0); //  不加括號(hào)會(huì)報(bào)錯(cuò)：ReferenceError: Invalid left-hand side in assignment
        } else {
            clientList[name] = fns.filter((item, index) => {
                return item !== cb; // filter不改變?cè)瓟?shù)組 return不忘記
            })
            /*
            // 反向遍歷
            for(let i = fns.length - 1; i >= 0; i--) {
                let _cb = fns[i];
                if(_cb === cb) {
                    fns.splice(i, 1);
                }
            }
            */
        }
    };

    return {
        listen: listen,
        trigger: trigger,
        remove: remove
    }

})();

let foo1 = function( num ){
    console.log("foo triggered");
}
let foo2 = function( num ){
    console.log(num);
}
Event.listen("foo", foo1);
Event.listen("foo", foo2);

Event.trigger("foo", 2);
// foo triggered
// 2

看下下面這段代碼的輸出，可以看到是無(wú)法取消對(duì)應(yīng)的訂閱信息的。就像{} === {}結(jié)果是 false一樣(引用類型的特點(diǎn)：按地址存放)。

Event.remove("foo", function(num){console.log(num)});
Event.trigger("foo", 2); 
// let obj1 = {};
// let obj2 = {};
//obj1 === obj2 // false
//but
//obj1 === obj1 // true

正確寫(xiě)法：

Event.remove("foo", foo2);
Event.trigger("foo", 2);

我們所了解的發(fā)布/訂閱模式，都是訂閱者必須先訂閱一個(gè)消息，隨后才能接收到發(fā)布者發(fā)布的消息。如果把順序反過(guò)來(lái)，發(fā)布者先發(fā)布一個(gè)消息，而在此之前并沒(méi)有對(duì)象來(lái)訂閱它，那么這條消息就消失在宇宙中了。

建立一個(gè)存放離線事件的堆棧，當(dāng)事件發(fā)布的時(shí)候，如果此時(shí)還沒(méi)有訂閱者來(lái)訂閱這個(gè)事件，我們暫時(shí)把發(fā)布事件的動(dòng)作包裹在一個(gè)函數(shù)里，這些包裝函數(shù)將被存入堆棧中，等到終于有對(duì)象來(lái)訂閱此事件的時(shí)候，我們將遍歷堆棧并且依次執(zhí)行這些包裝函數(shù)，也就是重新發(fā)布里面的事件。當(dāng)然離線事件的生命周期只有一次，就像QQ的未讀消息只會(huì)被重 新閱讀一次，所以剛才的操作我們只能進(jìn)行一次。

優(yōu)點(diǎn)：

發(fā)布—訂閱模式的優(yōu)點(diǎn)非常明顯：

時(shí)間上的解耦；

對(duì)象之間的解耦。

它的應(yīng)用非常廣泛,既可以用在異步編程中，也可以幫助我們完成更松耦合的代碼編寫(xiě)。發(fā)布/訂閱模式還可以用來(lái)幫助實(shí)現(xiàn)一些別的設(shè)計(jì)模式，比如中介者模式。

從架構(gòu)上來(lái)看，無(wú)論是 MVC 還是 MVVM,，都少不了發(fā)布/訂閱模式的參與，而且 JavaScript 本身也是一門基于事件驅(qū)動(dòng)的語(yǔ)言。

缺點(diǎn)：

當(dāng)然，發(fā)布/訂閱模式也不是完全沒(méi)有缺點(diǎn)。創(chuàng)建訂閱者本身要消耗一定的時(shí)間和內(nèi)存，而且當(dāng)你訂閱一個(gè)消息后，也許此消息最后都未發(fā)生，但這個(gè)訂閱者會(huì)始終存在于內(nèi)存中。

另外，發(fā)布/訂閱模式雖然可以弱化對(duì)象之間的聯(lián)系，但如果過(guò)度使用的話，對(duì)象和對(duì)象之間的必要聯(lián)系也將被深埋在背后，會(huì)導(dǎo)致程序難以跟蹤維護(hù)和理解。特別是有多個(gè)發(fā)布者和訂閱者嵌套到一起的時(shí)候，要跟蹤一個(gè) bug 不是件輕松的事情。