設計者模式之介面卡模式
摘要：
介面卡模式是設計模式中相對簡單的一種，它是將原本不同的內層介面通過改裝實現統一對外可以實現適配。生活中很多這樣的例項，比如usb轉接頭、萬能插座等。
案例
假設我們有使用百度地圖系統，但這部分的api不歸我們控制，也不允許我們改動，但我們需要進行一次封裝來實現對應的功能。
cons...
介面卡模式是設計模式中相對簡單的一種，它是將原本不同的內層介面通過改裝實現統一對外可以實現適配。生活中很多這樣的例項，比如usb轉接頭、萬能插座等。
案例
假設我們有使用百度地圖系統，但這部分的api不歸我們控制，也不允許我們改動，但我們需要進行一次封裝來實現對應的功能。
const BaiduMap ={
show:function(){
console.log('百度地圖')
}
}
const BaiduMapAdapter = function(){
show:function(){
return BaiduMap.show();
}
}
複製程式碼
除了這樣的例子之外，我們還有案例是基於一些引數的改造的，在裝飾者模式中我們講過可以對引數進行一些改造再返回給物件或者類，而介面卡模式本身就是可以做引數的改造，這樣一個過程。
比如，非常常見的，後端返回前端的資料，原來的列表格式是{name:'張三',id:1}，但是ui控制元件的要求是希望我們傳遞的資料物件的欄位是{label:'張三',value:1}.很多同學可能不會覺得這個引數改造有多麻煩，但實際上我們缺乏的是設計思想，是把這個引數改造的程式碼段變成一個可重用的具有設計思想的方法。說的更直白的話，就是這段更改賦值的方法根本不能複用，下次換其他具體的欄位，還要寫很多類似的方法。
let userList = [{name:'張三',id:1}];
//old codes
//vue methods
changeUserList(userList){
this.userList = userList.reduce((arr,item)=> {
arr.push({
label:item.name,
value:item.id
})
},[])
}
// new codes ,基於需要改造為label/value的元件，提供一個引數改造的工具方法
/**
@param arr 需要改造的陣列
@param itemOldKey :[label,value] ,需要改造為label、value的對應的原值
*/
const compParamAdapter = (arr,itemOldKey) => {
if(!Array.isArray(arr) ||!arr.length || !Array.isArray(itemOldKey)) return ;
return arr.reduce((arr,item)=>{
arr.push({
key:itemOldKey[0] ? item[itemOldKey[0]] :item.label,
value:itemOldKey[1] ? item[itemOldKey[1]] :item.value,
})
})
}
// 任何需要類似的改造的使用場景的時候，直接使用介面卡適配的結果
//vue methods
changeUserList(userList){
this.userList = compParamAdapter(userList,['name','id'])
}
複製程式碼
對比
因為到這裡，其實已經分享過了較多的設計模式了，相信大家對外觀模式、裝飾者模式和介面卡模式有一定疑惑，因為看程式碼沒什麼差別，都是進行一次封裝。這裡說幾點重要的區別。
- 介面卡模式主要是用來解決兩個介面不匹配的問題，或者也可以擴大為資料不匹配或者不完整的問題，介面卡不需要修改原來的介面或者資料，只是依照原來的介面或者資料進行改造，讓其符合要求。
- 裝飾者模式是為了給物件增加屬性或者功能或者改造引數，可能會形成一個長的裝飾鏈，並且需要提供被裝飾的物件，而介面卡模式不需要知道最終的使用者，再順便說下代理模式，是為了解決不暴露原物件的其他屬性而出發的。
- 外觀模式，外觀模式是和介面卡模式看似差別最小的，兩者的最主要的差別是，是否是新寫一個介面，還是改造一下還是用原來的第三方資料或者介面。
不管怎麼說，其實用哪種設計模式，不用過於計較概念，希望大家工作中更重要的是基於這些設計模式的思想解決實際的問題，以能解決問題為準，具體你解決後的這段程式碼屬於什麼設計模式的範疇可能不是那麼重要。