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

　　一、起因

　　在看《Ajax in action》的時候，看到它在介紹Adapter和Facade兩種模式。由于目前Web開發(fā)的特色，特別是客戶端Js腳本的開發(fā)，需要面對很多的變化和跨平臺的挑戰(zhàn)，所以，如果應(yīng)用Adapter和Facade模式，將會非常有益于提高我們軟件的可維護性，以及降低總體開發(fā)成本。

　　二、什么是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模式所要解決的問題，就是接口不一致的問題。在實際的應(yīng)用程序中，有的時候客戶端（這里指調(diào)用方）想要調(diào)用的接口與實際上服務(wù)端（這里指被調(diào)用方）所提供的接口不一致。出現(xiàn)這種情況，我們可能會有兩種選擇，一種是修改調(diào)用方或者被調(diào)用方的接口，使之互相適應(yīng)。另一種就是在調(diào)用方和被調(diào)用方之間加入一個Adapter，用其連接調(diào)用方和被調(diào)用方。

　　在Adapter模式里，Adapter所起的作用，就是一個接口適配器。一個Adapter類會實現(xiàn)（implements）調(diào)用方所期待的接口，并且在類中通過委派（delegate）來調(diào)用被調(diào)用方，從而實現(xiàn)兩種不同接口的連接。

　　1.3、分類：

　　Adapter模式分為兩種實現(xiàn)方式，一種是對象適配器（Object Adapters）和類適配器（Class Adapters）。其中對象適配器（Object Adapters）通過組合（composition）實現(xiàn)，而類適配器（Class Adapters）通過多繼承實現(xiàn)。

　　1.4、關(guān)鍵點：

　　模式的關(guān)鍵點在于其意圖。Adapter模式的意圖很明顯，就是為了使兩個彼此不兼容的接口兼容，使一個本來并不是調(diào)用方所期待的接口看起來跟所期待的一樣。

　　在《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模式的意圖也是非常明顯。有時候，我們的客戶端（調(diào)用方）所調(diào)用的子系統(tǒng)（subsystem，被調(diào)用方）過于復(fù)雜。通常，調(diào)用方需要連續(xù)調(diào)用被調(diào)用方的N個接口才能完成某種特定的任務(wù)。每次調(diào)用方重復(fù)調(diào)用操作都非常繁瑣，容易出錯，所以本著DRY（Don’t Repeat Yourself）的原則，我們需要提煉出一些經(jīng)常用到的操作組合成一個接口。這樣，每次調(diào)用方執(zhí)行該功能時，僅需要調(diào)用該Facade接口，便可以輕松執(zhí)行某項特定任務(wù)。

　　2.3、作用

　　Facade模式的作用主要有兩點：

　　1、為一個太復(fù)雜的子系統(tǒng)（subsystem）提供一個統(tǒng)一的、簡單的接口共調(diào)用方使用。通常需要DRY的接口都是使用率非常高，并且比較復(fù)雜的接口。將該接口提取出來，有益于簡化工作，并且統(tǒng)一接口名稱。

　　2、降低系統(tǒng)的耦合度。一批事物的變化率遠(yuǎn)大于一個事物。應(yīng)用Facade模式的情景，一般是由于子系統(tǒng)太復(fù)雜。當(dāng)調(diào)用方需要執(zhí)行某些任務(wù)時，需要執(zhí)行一連串操作。而隨著子系統(tǒng)的升級，這一連串操作的變化的可能性是非常大的。但是，不管子系統(tǒng)如何變，這一連串操作所提供的功能或者是意義永遠(yuǎn)不變。所以，F(xiàn)acade模式有利于降低耦合度。

　　2.4、關(guān)鍵點：

　　Facade模式的關(guān)鍵點在于，引入Facade模式主要是為了簡化和統(tǒng)一接口。Facade模式的接口一般是子系統(tǒng)的一個“快捷方式”。調(diào)用方如果還有其他的復(fù)雜功能的話，依然可以直接調(diào)用子系統(tǒng)的其他接口。

　　3、Adapter和Facade模式的區(qū)別

　　模式的區(qū)別就在于，要領(lǐng)會其根本的意圖。這里有一句話，描述了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開發(fā)所面臨的問題

　　Ajax時代的Web開發(fā)，有一個共同的特點。由于此時的瀏覽器端應(yīng)用再也不是傳統(tǒng)的簡單頁面，而變成了復(fù)雜的javascript客戶端應(yīng)用程序。所以，隨著代碼量的上升，要求我們用更加合乎軟工的方式去看待Ajax應(yīng)用程序。如果在此時能夠引入各種OO原則及模式，將會提高Ajax應(yīng)用程序的整體質(zhì)量。

　　目前在瀏覽器端進行javascript開發(fā)時，主要會面臨這么兩種問題：

　　1、目前的Web開發(fā)還比較混亂。各種瀏覽器對W3C標(biāo)準(zhǔn)的支持都有問題，并不統(tǒng)一。進行Web開發(fā)時，盡管我們一直提倡基于Web標(biāo)準(zhǔn)進行開發(fā)，但有時我們往往有些力不從心。

　　2、Web開發(fā)過程中所使用的各種瀏覽器API，其本身組合的也并不足夠合理。有時候為了執(zhí)行某項操作，我們需要連續(xù)操作很多接口。而實際上，在大多數(shù)情況下，我們都沒必要這么DRY（Do Repeat Yourself）.

　　你可以看到，其實上面兩種情況就分別對應(yīng)于設(shè)計模式中的Adapter和Façade兩種模式的需求。那么，下面讓我們看看如何在實際的代碼中應(yīng)用上述兩種模式解決問題？

　　四、如何應(yīng)用Adapter和Facade模式？

　　在《Ajax in action》中，同樣有一段代碼，體現(xiàn)了這樣的需求。我把它修改了一下，大家看看，能否從中找出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());
}
};

　　怎么樣，看到了嗎？沒有？那好，讓我來解釋一下這段代碼如何應(yīng)用Adapter和Facade模式的。當(dāng)然，這里并不分析具體代碼的含義了。

　　1、Adapter模式

　　在Ajax應(yīng)用中經(jīng)常用到的XHR（xmlHttpRequest）對象，就是需要Adapter模式的一個很好的例子。

　　XHR對象非W3C標(biāo)準(zhǔn)，所以，盡管現(xiàn)有的較新的瀏覽器都支持XHR對象，但其具體實現(xiàn)是不一致的。在微軟的IE里，XHR是以“ActiveXObject”的樣式實現(xiàn)的。而在mozilla瀏覽器里，其又以一種build-in對象的形式實現(xiàn)。天知道在其他的什么瀏覽器或者日后的日子里，這種實現(xiàn)方式會不會發(fā)生變化。

　　而對于我們常用的應(yīng)用程序來說，我們并不關(guān)心這些所有的細(xì)節(jié)。我們所需要知道的，就是當(dāng)我們希望創(chuàng)建一個XHR對象時，有一個XHR對象會被創(chuàng)建，并且供我們使用。至于究竟如何創(chuàng)建，我們對它并不關(guān)心。所以，你可以看到，在上面的代碼里，我們是通過在ContentLoader類的loadXMLDoc的方法中實現(xiàn)的。

if (window.XMLHttpRequest)
{
this.req=new XMLHttpRequest();
}
else if (window.ActiveXObject)
{
this.req=new ActiveXObject("Microsoft.XMLHTTP");
}

　　這里的一個IF語句幫助我們實現(xiàn)了跨平臺性，它便是一個Adapter。在這里，我們通過一點來自動適應(yīng)各種平臺的變化。我們的程序代碼期待一個統(tǒng)一的創(chuàng)建XHR的接口。這段代碼實現(xiàn)了這個接口，并且通過委托（delegate）的機制，自動幫我們用各種方法在各種不同的平臺下實例化一個XHR對象。

　　想象一下，在不遠(yuǎn)的未來，有一種Xbrower出現(xiàn)，并且非常紅火，值得我們兼容。我們只要改變我們的Adapter，就可以適應(yīng)該變化。而我們其他的客戶端代碼都不需要修改，豈不很好嗎？

　　2、Facade模式

　　當(dāng)你需要用XHR對象向服務(wù)器請求數(shù)據(jù)的時候，你總是會很痛苦的執(zhí)行一連串操作，僅僅是為了請求一次數(shù)據(jù)：

　　1、建立XHR對象

　　2、注冊callback函數(shù)

　　3、用open方法設(shè)置請求方式，地址，模式

　　4、用send發(fā)送請求

　　5、監(jiān)視請求的狀態(tài)，當(dāng)達到某一特定狀態(tài)時，執(zhí)行某項特殊功能。。。

　　天，好復(fù)雜，可是為什么我們要不斷地重復(fù)自己呢？

　　上面的ContentLoader類就可以很好的屏蔽這些復(fù)雜性。當(dāng)你想要從服務(wù)器端獲得一些數(shù)據(jù)的時候，你關(guān)心的是服務(wù)器端的數(shù)據(jù)，而不是這整個復(fù)雜的過程。通過應(yīng)用上面的這個ContentLoader類，你可以很輕松的用兩行代碼就獲得數(shù)據(jù)。

var myRequest = new CGIAJAX.util.ContentLoader(url, refreshTalbe);
myRequest.loadXMLDoc();

　　可以看到，實際上ContentLoader類就是一個簡單的接口，它將整個復(fù)雜的接口簡單化、統(tǒng)一化。如此一來，我們就可以DRY了。當(dāng)然，ContentLoader類并不會使我們的靈活性有所降低。如果你需要的話，你還是可以直接調(diào)用瀏覽器所提供的XHR接口的。可是大多數(shù)時候，我們只需要用ContentLoader類就可以很好的完成任務(wù)了。

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

　　五、警惕Ajax開發(fā)！

　　為何要警惕Ajax開發(fā)？

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

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