一、 起因
在看《AJax in action》的時候，看到它在介紹Adapter和Facade兩種模式。由於目前Web開發的特色，特別是客戶端JS腳本的開發，需要面對很多的變化和跨平台的挑戰，所以，如果應用Adapter和Facade模式，將會非常有益於提高我們軟件的可維護性，以及降低總體開發成本。
二、 什麼是Adapter和Facade模式
1、 Adapter模式
1.1、定義：
The Adapter Pattern converts the interface of a class into another interface the clIEnts expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.
1.2、解釋：
Adapter模式所要解決的問題，就是接口不一致的問題。在實際的應用程序中，有的時候客戶端（這裡指調用方）想要調用的接口與實際上服務端（這裡指被調用方）所提供的接口不一致。出現這種情況，我們可能會有兩種選擇，一種是修改調用方或者被調用方的接口，使之互相適應。另一種就是在調用方和被調用方之間加入一個Adapter，用其連接調用方和被調用方。
在Adapter模式裡，Adapter所起的作用，就是一個接口適配器。一個Adapter類會實現（implements）調用方所期待的接口，並且在類中通過委派（delegate）來調用被調用方，從而實現兩種不同接口的連接。
1.3、分類：
Adapter模式分為兩種實現方式，一種是對象適配器（Object Adapters）和類適配器（Class Adapters）。其中對象適配器（Object Adapters）通過組合（composition）實現，而類適配器（Class Adapters）通過多繼承實現。
1.4、關鍵點：
模式的關鍵點在於其意圖。Adapter模式的意圖很明顯，就是為了使兩個彼此不兼容的接口兼容，使一個本來並不是調用方所期待的接口看起來跟所期待的一樣。
在《Head.First.Design.Patterns》這本書裡，有一句話可以非常完美並且有趣的描述Adapter模式：
If it walks like a duck and quacks like a duck, then it might be a turkey wrapped with a duck adapter...
2、 Facade模式
2.1、定義：
The Facade Pattern provides a unified interface to a set of interfaces in subsystem. Facade defines a higher-level interface that makes the subsystem easIEr to use.
2.2、解釋：
Facade模式的意圖也是非常明顯。有時候，我們的客戶端（調用方）所調用的子系統（subsystem，被調用方）過於復雜。通常，調用方需要連續調用被調用方的N個接口才能完成某種特定的任務。每次調用方重復調用操作都非常繁瑣，容易出錯，所以本著DRY（Don’t Repeat Yourself）的原則，我們需要提煉出一些經常用到的操作組合成一個接口。這樣，每次調用方執行該功能時，僅需要調用該Facade接口，便可以輕松執行某項特定任務。
2.3、作用
Facade模式的作用主要有兩點：
1、 為一個太復雜的子系統（subsystem）提供一個統一的、簡單的接口共調用方使用。通常需要DRY的接口都是使用率非常高，並且比較復雜的接口。將該接口提取出來，有益於簡化工作，並且統一接口名稱。
2、 降低系統的耦合度。一批事物的變化率遠大於一個事物。應用Facade模式的情景，一般是由於子系統太復雜。當調用方需要執行某些任務時，需要執行一連串操作。而隨著子系統的升級，這一連串操作的變化的可能性是非常大的。但是，不管子系統如何變，這一連串操作所提供的功能或者是意義永遠不變。所以，Facade模式有利於降低耦合度。
2.4、關鍵點：
Facade模式的關鍵點在於，引入Facade模式主要是為了簡化和統一接口。Facade模式的接口一般是子系統的一個“快捷方式”。調用方如果還有其他的復雜功能的話，依然可以直接調用子系統的其他接口。
3、 Adapter和Facade模式的區別
模式的區別就在於，要領會其根本的意圖。這裡有一句話，描述了Adapter和Facade模式以及Decorator模式（這裡可以先不管decorator模式）。
An adapter wraps an object to change its interface, a decorator wraps an object to add new behaviors and responsibilitIEs, and a facade "wraps" a set of objects to simplify.
三、 Web開發所面臨的問題
AJax時代的Web開發，有一個共同的特點。由於此時的浏覽器端應用再也不是傳統的簡單頁面，而變成了復雜的JavaScript客戶端應用程序。所以，隨著代碼量的上升，要求我們用更加合乎軟工的方式去看待AJax應用程序。如果在此時能夠引入各種OO原則及模式，將會提高AJax應用程序的整體質量。
目前在浏覽器端進行JavaScript開發時，主要會面臨這麼兩種問題：
1、 目前的Web開發還比較混亂。各種浏覽器對W
2、 Web開發過程中所使用的各種浏覽器API，其本身組合的也並不足夠合理。有時候為了執行某項操作，我們需要連續操作很多接口。而實際上，在大多數情況下，我們都沒必要這麼DRY（Do Repeat Yourself）.
你可以看到，其實上面兩種情況就分別對應於設計模式中的Adapter和Façade兩種模式的需求。那麼，下面讓我們看看如何在實際的代碼中應用上述兩種模式解決問題？
四、 如何應用Adapter和Facade模式？
在《AJax in action》中，同樣有一段代碼，體現了這樣的需求。我把它修改了一下，大家看看，能否從中找出Adapter和Facade模式的影子？
CGIAJax.util["STATICS"] = {};
CGIAJax.util.STATICS.READY_STATE_UNINITIALIZED=0;//constant
CGIAJax.util.STATICS.READY_STATE_LOADING=1;
CGIAJax.util.STATICS.READY_STATE_LOADED=2;
CGIAJax.util.STATICS.READY_STATE_INTERACTIVE=3;
CGIAJax.util.STATICS.READY_STATE_COMPLETE=4;
CGIAJax.util.ContentLoader = function(url, onload, method, msgBody, onerror)//constructor, contains all attributes
{
this.url=url;
this.onload=onload;
this.method = (method) ? method : "GET";//default value of method is GET
this.msgBody = (msgBody) ? msgBody : null;//default value of message body send to server
this.onerror=(onerror) ? onerror : this.defaultError;//default method to handle error
this.req=null;
}
//contains all method
CGIAJax.util.ContentLoader.prototype=
{
loadXMLDoc:function()//send request to server to get response
{
if (window.XMLHttpRequest)
{
this.req=new XMLHttpRequest();
}
else if (window.ActiveXObject)
{
this.req=new ActiveXObject("Microsoft.XMLHTTP");
}
if (this.req)
{
try
{
var loader=this;
this.req.onreadystatechange=function()
{
loader.onReadyState.call(loader);
}
if ("GET" == this.method)
{
this.req.open('GET',this.url,true);
this.req.send(null);
}
else
{
if (!this.msgBody)
{
this.onerror.call(this);
}
this.req.open(this.method,this.url,true);
this.req.send(this.msgBody);
}
}
catch (err)
{
this.onerror.call(this);
}
}
},
onReadyState:function()
{
var req=this.req;
var ready=req.readyState;
if (ready==CGIAJax.util.STATICS.READY_STATE_COMPLETE)
{
var httpStatus=req.status;
if (httpStatus==200 || httpStatus==0)
{
this.onload.call(this);
}
else
{
this.onerror.call(this);
}
}
},
defaultError:function()//default error handler
{
alert("error fetching data!"
+"\n\nreadyState:"+this.req.readyState
+"\nstatus: "+this.req.status
+"\nheaders: "+this.req.getAllResponseHeaders());
}
};
怎麼樣，看到了嗎？沒有？那好，讓我來解釋一下這段代碼如何應用Adapter和Facade模式的。當然，這裡並不分析具體代碼的含義了。
1、 Adapter模式
在AJax應用中經常用到的XHR（XMLHttpRequest）對象，就是需要Adapter模式的一個很好的例子。
XHR對象非W
而對於我們常用的應用程序來說，我們並不關心這些所有的細節。我們所需要知道的，就是當我們希望創建一個XHR對象時，有一個XHR對象會被創建，並且供我們使用。至於究竟如何創建，我們對它並不關心。所以，你可以看到，在上面的代碼裡，我們是通過在ContentLoader類的loadXMLDoc的方法中實現的。
if (window.XMLHttpRequest)
{
this.req=new XMLHttpRequest();
}
else if (window.ActiveXObject)
{
this.req=new ActiveXObject("Microsoft.XMLHTTP");
}
這裡的一個IF語句幫助我們實現了跨平台性，它便是一個Adapter。在這裡，我們通過一點來自動適應各種平台的變化。我們的程序代碼期待一個統一的創建XHR的接口。這段代碼實現了這個接口，並且通過委托（delegate）的機制，自動幫我們用各種方法在各種不同的平台下實例化一個XHR對象。
想象一下，在不遠的未來，有一種Xbrower出現，並且非常紅火，值得我們兼容。我們只要改變我們的Adapter，就可以適應該變化。而我們其他的客戶端代碼都不需要修改，豈不很好嗎？
2、 Facade模式
當你需要用XHR對象向服務器請求數據的時候，你總是會很痛苦的執行一連串操作，僅僅是為了請求一次數據：
1、 建立XHR對象
2、 注冊callback函數
3、 用open方法設置請求方式，地址，模式
4、 用send發送請求
5、 監視請求的狀態，當達到某一特定狀態時，執行某項特殊功能。。。
天，好復雜，可是為什麼我們要不斷地重復自己呢？
上面的ContentLoader類就可以很好的屏蔽這些復雜性。當你想要從服務器端獲得一些數據的時候，你關心的是服務器端的數據，而不是這整個復雜的過程。通過應用上面的這個ContentLoader類，你可以很輕松的用兩行代碼就獲得數據。
var myRequest = new CGIAJax.util.ContentLoader(url, refreshTalbe);
myRequest.loadXMLDoc();
可以看到，實際上ContentLoader類就是一個簡單的接口，它將整個復雜的接口簡單化、統一化。如此一來，我們就可以DRY了。當然，ContentLoader類並不會使我們的靈活性有所降低。如果你需要的話，你還是可以直接調用浏覽器所提供的XHR接口的。可是大多數時候，我們只需要用ContentLoader類就可以很好的完成任務了。
再想象一下。假如說未來W
五、 警惕AJax開發！
為何要警惕AJax開發？
眾所周知，由於AJax導致Web開發模式上的變化，將會導致客戶端代碼的激增，由量變變成質變。而且最重要的是，AJax現在所用到的各種技術，很大一部分都還沒有成為標准，或者剛剛成為標准。這就意味著，這些東西會在未來的一段時間內，頻繁變化。如果我們應用程序設計時，對該方面的變化有所准備，那麼到頭來痛苦的只有我們自己。
在AJax開發中應用OO模式以及OO原則，最重要的並不是炫耀某種技術，而是期望這種已被證明的強大技術能夠為我們的開發帶來根本上的好處。