有的時候在開發過程中，我們會發現，客戶端需要的接口和提供的接口發生不兼容的問題。由於特殊的原因我們無法修改客戶端接口。在這種情況下，我們需要適配現有接口和不兼容的類，這就要提到適配器模式。通過適配器，我們可以在不用修改舊代碼的情況下也能使用它們，這就是適配器的能力。
適配模式可用來在現有接口和不兼容的類之間進行適配，使用這種模式的對象又叫包裝器（wrapper），因為它們是在用一個新的接口包裝另一個對象。
從表面上看，適配器模式很像外觀模式。它們都要對別的對象進行包裝並改變其呈現的接口。二者的差別在於它們如何改變接口。外觀元素展現的是一個簡化的接口，它並不提供額外的選擇，而且有時為了方便完成常見任務它還會做出一些假定。而適配器則要把一個接口轉換為另一個接口，它並不會濾除某些能力，也不會簡化接口。如果客戶系統API不可用，就需要用到適配器。
基本理論
適配器模式：將一個接口轉換成客戶端需要的接口而不需要去修改客戶端代碼，使得不兼容的代碼可以一起工作。
適配器主要有3個角色組成：
（1）客戶端：調用接口的類
（2）適配器：用來連接客戶端接口和提供服務的接口的類
（3）適配者：提供服務，但是卻與客戶端接口需求不兼容服務類。
適配器模式的實現
1.最簡單的適配器
適配器模式沒有想像中的那麼複雜，舉個最簡單的例子。
客戶端調用一個方法進行加法計算：
var result = add(1,2);
但是我們沒有提供add這個方法，提供了同樣類似功能的sum方法：
function sum(v1,v2){ return v1 + v2;}為了避免修改客戶端和服務端，我們增加一個包裝函數：
function add (v1,v2){ reutrn sum(v1,v2);}這就是一個最簡單的適配器模式，我們在兩個不兼容的接口之間添加一個包裝方法，用這個方法來連接二者使其共同工作。
2.實際應用
隨著前端框架的發展，越來越多的開發者開始使用MVVM框架進行開發，只需要操作數據而不需要操作DOM元素，jQuery的作用越來越少。而很多項目中還是引用著jQuery庫作用工具類，因為我們要利用jQuery提供的ajax去服務器請求數據。如果jQuery在項目中的作用僅僅是作為ajax工具庫的話，有點殺雞焉用牛刀的感覺，造成資源浪費。這個時候我們完全可以封裝一個自己的ajax庫。
假設我們封裝的ajax就通過一個函數進行使用：
ajax({ url:'/getData', type:'Post', dataType:'json', data:{ id:"123" }}).done(function(){})除了調用接口ajax與jQuery的$.ajax的不同，其他完全一樣。
項目中請求ajax的地方必然很多，我們替換jQuery的時候不可能一個一個去修改$.ajax，那怎麼辦呢，這個時候，我們就可以增加一個適配器：
var $ = { ajax:function (options){ return ajax(options); }}這樣就能兼容舊代碼和新接口，避免對已有的代碼的修改。
總結
適配器模式的原理很簡單，就是新增一個包裝類，對新的接口進行包裝以適應舊代碼的調用，避免修改接口和調用代碼。
適用場景：存在較多代碼調用舊接口，為了避免修改舊代碼和更換新接口，不影響現有實現方式的應用場景。
1.適配器模式的適用場合：
適配器適用於客戶系統期待的接口與現有API提供的接口不兼容這種場合。適配器所適配的兩個方法執行的應該是類似的任務，否則的話就解決不了問題。就像橋接元素和外觀元素一樣，通過創建適配器，可以把抽象與其實現隔離開來，以便二者獨立變化。
2.適配器模式之利：
用一個新的接口對現有類的接口進行包裝，這樣客戶程序就能使用這個並非為其量身打造的類而又無需為此大動手術。
3.設配器模式之弊：
有人認為適配器是一種不必要的開銷，完全可以通過重寫現有代碼避免。此外適配器模式也會引入一批需要支持的新工具。如果現有API還未定形，或者新接口還未定形，那麼適配器可能不會一直管用。
在涉及大型系統和遺留框架的情況下，它的優點往往比缺點更突出。