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

　　適配器模式是設計模式行爲型模式中的一種模式；

　　定義：

　　適配器用來解決兩個已有接口之間不匹配的問題，它並不須要考慮接口是如何實現，也不用考慮未來該如何修改；適配器不須要修改已有接口，就可使他們協同工做；

　　白話解釋：

　　　你買了某種電器產品，準備帶回家好好感覺該款產品的魅力；結果帶回家以後準備通電使用的時候，發現該產品僅支持兩孔插座，而你家裏的電源插座都是三孔插座；這個時候你總不能又跑去電器專賣店退貨吧；忽然靈機一動，你想起來了家裏還有多功能電源插座，而多功能電源插座剛好就是三孔，因而你拿出你的多功能電源插座插上電源插座，再拿你電器產品的電源插座插在多功能插座上面的兩孔插座上，開始享受美滋滋的生活；這裏的多功能插座就是一個適配器；

　　代碼實現：

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 ); // 開始渲染百度地圖

 

　　固然上面的代碼是可以正常運行的，這得益於這兩個對象中的參數名都是同樣的，因此纔可以正常的運行和顯示；

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

　　忽然有一天若是baiduMap的方法名改變了呢？那麼咱們再跟上面同樣運行確定是會報錯的，由於baiduMap對象中已經沒有了show()這個方法了；

　　使用適配器模式來修改：

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

    }
};

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

　　在這段代碼中適配器作的事情其實很簡單，就是建立了一個對象，添加了一個同名的show()方法，而後在適配器裏面調用了baiduMap.display()方法，這樣咱們只須要在調用baiduMap的時候調用咱們的適配器便可達到預期效果；

 

　　咱們做爲前端開發人員，對頁面上期待獲得的數據和數據格式確定是比較瞭解的，可是在先後端分離的開發模式中有的時候會遇到這種尷尬的處境：

　　咱們都知道不少UI組件或者工具庫會按指定的數據格式進行渲染，可是這個時候後端是不知道的；因此可能接口出來的數據咱們是不能直接正常的在頁面上渲染的，而此時老闆催促咱們趕忙上線，然後端堅持認爲數據格式沒問題，堅定不修改；這個時候咱們能夠經過適配器模式來前端格式化數據；

　　後端返回的json數據格式：

[
  {
    "day": "週一",
    "uv": 6300
  },
  {
    "day": "週二",
    "uv": 7100
  },  {
    "day": "週三",
    "uv": 4300
  },  {
    "day": "週四",
    "uv": 3300
  },  {
    "day": "週五",
    "uv": 8300
  },  {
    "day": "週六",
    "uv": 9300
  }, {
    "day": "週日",
    "uv": 11300
  }
]

　　Echarts圖表圖形須要的數據格式：

["週二", "週二", "週三"， "週四"， "週五"， "週六"， "週日"] //x軸的數據

[6300. 7100, 4300, 3300, 8300, 9300, 11300] //座標點的數據

　　雖然內心苦，但仍是要解決問題！使用適配器來解決：

//x軸適配器
function echartXAxisAdapter(res) {
  return res.map(item => item.day);
}

//座標點適配器
function echartDataAdapter(res) {
  return res.map(item => item.uv);
}

　　建立兩個函數分別對數據按照echarts所須要的數據格式進行格式化處理便可解決問題；這兩個方法其實就是一個適配器，把指定的數據丟進去便可按照指定規則輸出咱們期待獲得的數據格式；

　　

　　總結：

　　　我的認爲適配器模式實際上是一種亡羊補牢式的設計模式，若是在項目開發的開始階段咱們就知道咱們期待的數據格式或者方法名等，咱們就可能永遠都用不到適配器模式；可是項目的迭代每每是不可預期的，當項目迭代以後數據格式或者方法名發生變化以後，咱們一般可使用適配器模式來進行適配解決；固然了，最好的解決辦法就是項目開發過程當中先後端協商討論數據格式、文件名等代碼規範，這樣是對項目的開發效率是會有很大的提高的；