推薦：AJAX編程實踐之與服務器通信
　　首先看下看下相對簡單些的--向服務器發送一個包含有名/值對的簡單查詢串，在這種情況下XHP即可以用GET也可以用POST。 GETfunction doRequestUsingGET() {　createXMLHttpRequest();　v

　　一、起因

　　在看《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開發還比較混亂。各種瀏覽器對W3C標準的支持都有問題，并不統一。進行Web開發時，盡管我們一直提倡基于Web標準進行開發，但有時我們往往有些力不從心。

　　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對象非W3C標準，所以，盡管現有的較新的瀏覽器都支持XHR對象，但其具體實現是不一致的。在微軟的IE里，XHR是以“ActiveXObject”的樣式實現的。而在mozilla瀏覽器里，其又以一種build-in對象的形式實現。天知道在其他的什么瀏覽器或者日后的日子里，這種實現方式會不會發生變化。

　　而對于我們常用的應用程序來說，我們并不關心這些所有的細節。我們所需要知道的，就是當我們希望創建一個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類就可以很好的完成任務了。

　　再想象一下。假如說未來W3C將XHR作為標準，并且擴充了XHR接口的功能，那么我們怎么辦？很可能擴充功能的代價就是接口的變化或者接口調用順序的變化。如果我們沒有應用Facade模式，我們會怎樣？逐個修改代碼中每一個用到XHR的地方？知道一切運轉起來看似沒有問題？或者我們現在就應用Facade模式，到時候，我們就可以輕松的修改一下Facade模式所涉及的接口內容，然后跑去看NBA了，不是嗎？

　　五、警惕Ajax開發！

　　為何要警惕Ajax開發？

　　眾所周知，由于Ajax導致Web開發模式上的變化，將會導致客戶端代碼的激增，由量變變成質變。而且最重要的是，Ajax現在所用到的各種技術，很大一部分都還沒有成為標準，或者剛剛成為標準。這就意味著，這些東西會在未來的一段時間內，頻繁變化。如果我們應用程序設計時，對該方面的變化有所準備，那么到頭來痛苦的只有我們自己。

　　在Ajax開發中應用OO模式以及OO原則，最重要的并不是炫耀某種技術，而是期望這種已被證明的強大技術能夠為我們的開發帶來根本上的好處。