javascript設計模式——適配器模式

前面的話

　　適配器模式的作用是解決兩個軟體實體間的介面不相容的問題。使用適配器模式之後，原本由於介面不相容而不能工作的兩個軟體實體可以一起工作。適配器的別名是包裝器（wrapper），這是一個相對簡單的模式。在程式開發中有許多這樣的場景：當試圖調用模塊或者對象的某個介面時，卻發現這個介面的格式並不符合目前的需求。這時候有兩種解決辦法，第一種是修改原來的介面實現，但如果原來的模塊很複雜，或者拿到的模塊是一段別人編寫的經過壓縮的代碼，修改原介面就顯得不太現實了。第二種辦法是創建一個適配器，將原介面轉換為客戶希望的另一個介面，客戶只需要和適配器打交道。本文將詳細介紹適配器模式

現實中的適配器

　　適配器在現實生活的應用非常廣泛，接下來來看幾個現實生活中的適配器模式

　　1、港式插頭轉換器

　　港式的電器插頭比大陸的電器插頭體積要大一些。如果從香港買了一個Macbook，會發現充電器無法插在家裡的插座上，為此而改造家裡的插座顯然不方便，所以需要一個適配器：

　　2、電源適配器

　　Macbook電池支持的電壓是20V，日常生活中的交流電壓一般是220V。除了瞭解的220V交流電壓，日本和南韓的交流電壓大多是100V，而英國和澳大利亞的是240V。筆記本電腦的電源適配器就承擔了轉換電壓的作用，電源適配器使筆記本電腦在100V~240V的電壓之內都能正常工作，這也是它為什麼被稱為電源“適配器”的原因

　　3、USB轉介面

　　在以前的電腦上，PS2介面是連接滑鼠、鍵盤等其他外部設備的標準介面。但隨著技術的發展，越來越多的電腦開始放棄了PS2介面，轉而僅支持USB介面。所以那些過去生產出來的只擁有PS2介面的滑鼠、鍵盤、游戲手柄等，需要一個USB轉介面才能繼續正常工作，這是PS2-USB適配器誕生的原因

應用

　　如果現有的介面已經能夠正常工作，那就永遠不會用上適配器模式。適配器模式是一種“亡羊補牢”的模式，沒有人會在程式的設計之初就使用它。因為沒有人可以完全預料到未來的事情，也許現在好好工作的介面，未來的某天卻不再適用於新系統，那麼可以用適配器模式把舊介面包裝成一個新的介面，使它繼續保持生命力。比如在JSON格式流行之前，很多cgi返回的都是XML格式的數據，如果今天仍然想繼續使用這些介面，顯然可以創造一個XML-JSON的適配器

　　下麵是一個實例，向googleMap和baiduMap都發出“顯示”請求時，googleMap和baiduMap分別以各自的方式在頁面中展現了地圖：

var googleMap = {
    show: function(){
        console.log( '開始渲染谷歌地圖' );
    }
};
var baiduMap = {
    show: function(){
        console.log( '開始渲染百度地圖' );
    }
};
var renderMap = function( map ){
    if ( map.show instanceof Function ){
        map.show();
    }
};

renderMap( googleMap ); // 輸出：開始渲染谷歌地圖
renderMap( baiduMap ); // 輸出：開始渲染百度地圖

　　這段程式得以順利運行的關鍵是googleMap和baiduMap提供了一致的show方法，但第三方的介面方法並不在控制範圍之內，假如baiduMap提供的顯示地圖的方法不叫show而叫display呢？

　　baiduMap這個對象來源於第三方，正常情況下都不應該去改動它。此時可以通過增加baiduMapAdapter來解決問題：

var googleMap = {
    show: function(){
        console.log( '開始渲染谷歌地圖' );
    }
};
var baiduMap = {
    display: function(){
        console.log( '開始渲染百度地圖' );
    }
};
var baiduMapAdapter = {
    show: function(){
        return baiduMap.display();

    }
};

renderMap( googleMap ); // 輸出：開始渲染谷歌地圖
renderMap( baiduMapAdapter ); // 輸出：開始渲染百度地圖

　　再看看另一個例子。假設正在編寫一個渲染北京市地圖的頁面。目前從第三方資源里獲得了北京市的所有地區以及它們所對應的ID，並且成功地渲染到頁面中：

var getBeijingCity = function(){
    var beijingCity = [
    {
        name: 'chaoyang',
        id: 11,
    }, {
        name: 'haidian',
        id: 12,
    }
    ];
    return beijingCity;
};
var render = function( fn ){
    console.log( '開始渲染北京市地圖' );
    document.write( JSON.stringify( fn() ) );
};
render( getBeijingCity );

　　利用這些數據，編寫完成了整個頁面，並且線上上穩定地運行了一段時間。但後來發現這些數據不太可靠，裡面還缺少很多地區。於是又在網上找到了另外一些數據資源，這次的數據更加全面，但遺憾的是，數據結構和正運行在項目中的並不一致。新的數據結構如下：

var BeijingCity = {
    chaoyang: 11,
    haidian: 12,
    pinggu: 13
};

　　除了大動干戈地改寫渲染頁面的前端代碼之外，另外一種更輕便的解決方式就是新增一個數據格式轉換的適配器：

var getBeijingCity = function(){
    var beijingCity = [
    {
        name: 'chaoyang',
        id: 11,
    }, {
        name: 'haidian',
        id: 12,
    }

    ];
    return beijingCity;
};
var render = function( fn ){
    console.log( '開始渲染北京市地圖' );
    document.write( JSON.stringify( fn() ) );
};
var addressAdapter = function( oldAddressfn ){
    var address = {},
    oldAddress = oldAddressfn();
    for ( var i = 0, c; c = oldAddress[ i++ ]; ){
        address[ c.name ] = c.id;
    }
    return function(){
        return address;
    }
};
render( addressAdapter( getBeijingCity ) );

　　那麼接下來需要做的，就是把代碼中調用getBeijingCity的地方，用經過addressAdapter適配器轉換之後的新函數來代替

總結

　　適配器模式是一對相對簡單的模式。有一些模式跟適配器模式的結構非常相似，比如裝飾者模式、代理模式和外觀模式。這幾種模式都屬於“包裝模式”，都是由一個對象來包裝另一個對象。區別它們的關鍵仍然是模式的意圖。適配器模式主要用來解決兩個已有介面之間不匹配的問題，它不考慮這些介面是怎樣實現的，也不考慮它們將來可能會如何演化。適配器模式不需要改變已有的介面，就能夠使它們協同作用。裝飾者模式和代理模式也不會改變原有對象的介面，但裝飾者模式的作用是為了給對象增加功能。裝飾者模式常常形成一條長的裝飾鏈，而適配器模式通常只包裝一次。代理模式是為了控制對對象的訪問，通常也只包裝一次。外觀模式的作用倒是和適配器比較相似，有人把外觀模式看成一組對象的適配器，但外觀模式最顯著的特點是定義了一個新的介面