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

　　一、起因

　　在看《Ajax in action》的時(shí)候，看到它在介紹Adapter和Facade兩種模式。由于目前Web開(kāi)發(fā)的特色，特別是客戶(hù)端Js腳本的開(kāi)發(fā)，需要面對(duì)很多的變化和跨平臺(tái)的挑戰(zhàn)，所以，如果應(yīng)用Adapter和Facade模式，將會(huì)非常有益于提高我們軟件的可維護(hù)性，以及降低總體開(kāi)發(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、解釋?zhuān)?/P>

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

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

　　1.3、分類(lèi)：

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

　　1.4、關(guān)鍵點(diǎn)：

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

　　在《Head.First.Design.Patterns》這本書(shū)里，有一句話(huà)可以非常完美并且有趣的描述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、解釋?zhuān)?/P>

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

　　2.3、作用

　　Facade模式的作用主要有兩點(diǎn)：

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

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

　　2.4、關(guān)鍵點(diǎn)：

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

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

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

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

　　目前在瀏覽器端進(jìn)行javascript開(kāi)發(fā)時(shí)，主要會(huì)面臨這么兩種問(wèn)題：

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

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

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

　　四、如何應(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());
}
};

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

　　1、Adapter模式

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

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

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

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

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

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

　　2、Facade模式

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

　　1、建立XHR對(duì)象

　　2、注冊(cè)callback函數(shù)

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

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

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

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

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

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

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

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

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

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

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

　　在Ajax開(kāi)發(fā)中應(yīng)用OO模式以及OO原則，最重要的并不是炫耀某種技術(shù)，而是期望這種已被證明的強(qiáng)大技術(shù)能夠?yàn)槲覀兊拈_(kāi)發(fā)帶來(lái)根本上的好處。