【讀書筆記】讀《JavaScript設計模式》之橋接模式

橋接模式（Bridge）將抽象部分與它的實現部分分離，使它們均可以獨立地變化。

 

1、使用場景

　　使用場景一：事件監控

　　對於前端而言，最典型的使用場景——事件監控。如——

addEvent(element, 'click', getBeerById);

// 能夠看出這是一個只能工做在瀏覽器中的API，根據時間監聽期回調函數的工做機制，事件對象會被做爲第一個參數傳遞給這個函數。
// 在本例中並無使用這個參數，而只是從this對象獲取ID。若是你對這個API函數作單元測試，就很困難了。
// 對於API開發者來講，最好從一個優良的API開始，不要把它與任何特定的實現攪在一塊兒。
function getBeerById(e) {
    var id = this.id;
    asyncRequest('GET', 'beer.uri?id=' + id, function(resp) {
        // callback response
        console.log('Requested Beer:' + resp.responseText);
    });
}

　　咱們但願全部人都能獲取到啤酒的信息。也就是將獲取啤酒信息的方法造成共有API。

// 有利於獨立的單元測試
// 因爲單獨抽離了業務邏輯，在必定程度上，提升了代碼的複用性。
function getBeerById(id, callback) {
    // Make request for beer by ID, then return the beer data
    asyncRequest('GET', 'beer.uri?id=' + id, function(resp) {
        // callback response
        callback(resp.responseText);
    });
}

// 接下來，咱們將針對接口而不是實現進行編程，用橋接模式把抽象隔離開來。
addEvent(element, 'click', getBeerById);
// 有了這層橋接元素，這個API的使用範圍打打擴寬了，這給了你更大的設計自由。
// 由於如今getBeerById並無和事件對象捆綁在一塊兒，你能夠在單元測試中運行這個API。只需提供一個ID和回調函數便可。
function getBeerByIdBridge(e) {
    getBeerById(this.id, function(beer) {
        console.log('Requested Beer:' + beer);
    });
}

　　使用場景二：特權函數

　　提供共有API（即這裏的橋接函數）來訪問私有屬性或者方法——

// 除了在事件回調函數與接口之間進行橋接外，橋接模式也能夠用於鏈接公開的API代碼和私有的實現代碼
var Public = function() {
    var secret = 3;

    // 使用橋接模式來訪問某些私有的信息。這裏的橋接函數也稱爲特權函數
    this.privilegedGetter = function() {
        return secret++;
    };
};

var o = new Public();
var data = o.privilegedGetter();

　　使用場景三：實現組合

　　在顯示生活中，橋樑能夠把多種事物聯接起來，在JavaScript也是如此——

var Class1 = function(a, b, c) {
    this.a = a;
    this.b = b;
    this.c = c;
};

var Class2 = function(d) {
    this.d = d;
};

// 有了這個橋接元素，Class1和Class2可以獨立於BridgeClass而發生改變
var BridgeClass = function(a, b, c, d) {
    this.one = new Class1(a, b, c);
    this.two = new Class2(d);
};

 

2、使用原則

　　很難想象，不使用橋接模式的事件驅動編程回事什麼樣子。可是js編程新手們經常沉迷於事件驅動開發的函數式風格，忘了編寫接口。哪怕面對的是複雜操做。判斷什麼地方應該使用橋接模式一般很簡單。假若有下面的代碼：

$('#example').click(function() {
    new RichTextEditor();
});

　　從中你沒法看出那個編輯器要顯示在什麼地方、它有些什麼配置選項以及應該怎樣修改它。這裏的要訣是讓接口「可橋接」，實際上也就是可適配。

在現實生活中，橋樑對於城市建設和城中街道的聯通相當重要。城區至關於模塊，而街道至關於把他們鏈接在一塊兒的方法。 道路的可用性每每影響着該片區的人口數量。一樣，你向客戶提供的接口極有可能影響到模塊的受歡迎程度。

 

3、優點及劣勢

優點：

　　把抽象與其現實隔離開來，有助於獨立地管理軟件的各組成部分。達到充分解耦。Bug也所以更容易查找，而軟件發生嚴重故障的可能性也減少了。有利於分層，從而產生更好的結構化系統。說到底，橋接元素應該是粘合每個抽象的粘合因子。

劣勢：

　　在咱們看來，這種模式並無多少真正的缺點。前面講述它的優勢的時候已經提過，它置灰讓API更加健壯、提升組件的模塊化程度並促成更簡潔的客戶系統實現。不過這些益處的確是有代價的。每使用一個橋接元素都要增長一次函數調用，這對應用程序的性能會有一些負面影響。此外，它們提升了系統的複雜程度，在出現問題時這回致使代碼更難調試。大多數狀況下橋接模式都很是有用，但注意不要濫用。舉個例子來講，若是一個橋接函數被用於鏈接兩個函數，而其中某個函數根本不會在橋接函數以外被調用，那麼此時這個橋接函數就不是非要不可，你能夠放心將它刪除。

 

源自：JavaScript設計模式（人民郵電出版社）——第八章，橋接模式

參考：深刻理解JavaScript系列（44）：設計模式之橋接模式