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

標籤：充電器   Google   介紹   另一個   ada   工作   ons   串連   轉換器   

前面的話

　　適配器模式的作用是解決兩個軟體實體間的介面不相容的問題。使用適配器模式之後，原本由於介面不相容而不能工作的兩個軟體實體可以一起工作。適配器的別名是封裝器（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( ‘開始渲染Google地圖‘ );    }};var baiduMap = {    show: function(){        console.log( ‘開始渲染百度地圖‘ );    }};var renderMap = function( map ){    if ( map.show instanceof Function ){        map.show();    }};renderMap( googleMap ); // 輸出：開始渲染Google地圖renderMap( baiduMap ); // 輸出：開始渲染百度地圖

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

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

var googleMap = {    show: function(){        console.log( ‘開始渲染Google地圖‘ );    }};var baiduMap = {    display: function(){        console.log( ‘開始渲染百度地圖‘ );    }};var baiduMapAdapter = {    show: function(){        return baiduMap.display();    }};renderMap( googleMap ); // 輸出：開始渲染Google地圖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適配器轉換之後的新函數來代替

 

總結

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

 

 

 

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