|
|
我們?nèi)タ萍际袌鰹樽约旱臋C(jī)器添加點(diǎn)奢侈的配件，很多DIYer都喜歡去找代理商，因?yàn)樵诖砩棠抢锬玫降臇|西不僅質(zhì)量有保證，而且價格和售后服務(wù)上都會好很多。客戶通過代理商得到了自己想要的東西，而且還享受到了代理商額外的服務(wù)；而生產(chǎn)廠商通過代理商將自己的產(chǎn)品推廣出去，而且可以將一些銷售服務(wù)的任務(wù)交給代理商來完成（當(dāng)然代理商要和廠商來共同分擔(dān)風(fēng)險，分配利潤），這樣自己就可以花更多的心思在產(chǎn)品的設(shè)計(jì)和生產(chǎn)上了。
在美國，任何企業(yè)的產(chǎn)品要想拿到市場上去賣就必須經(jīng)過代理商這一個環(huán)節(jié)，否則就是非法的。看來代理商在商業(yè)運(yùn)作中起著很關(guān)鍵的作用。 不小心把話題扯遠(yuǎn)了，回過頭來，那么在我們的面向?qū)ο蟮某绦蛟O(shè)計(jì)中，會不會有代理商這樣的角色呢？來看這篇文章的人肯定不會說：沒有！
那么就跟著這篇文章來看看代理模式的奇妙吧。
二、定義和分類
代理模式在設(shè)計(jì)模式中的定義就是：為其他對象提供一種代理以控制對這個對象的訪問。說白了就是，在一些情況下客戶不想或者不能直接引用一個對象，而代理對象可以在客戶和目標(biāo)對象之間起到中介作用，去掉客戶不能看到的內(nèi)容和服務(wù)或者增添客戶需要的額外服務(wù)。
那么什么時候要使用代理模式呢？在對已有的方法進(jìn)行使用的時候出現(xiàn)需要對原有方法進(jìn)行改進(jìn)或者修改，這時候有兩種改進(jìn)選擇：修改原有方法來適應(yīng)現(xiàn)在的使用方式，或者使用一個“第三者”方法來調(diào)用原有的方法并且對方法產(chǎn)生的結(jié)果進(jìn)行一定的控制。第一種方法是明顯違背了“對擴(kuò)展開放、對修改關(guān)閉”（開閉原則），而且在原來方法中作修改可能使得原來類的功能變得模糊和多元化（就像現(xiàn)在企業(yè)多元化一樣），而使用第二種方式可以將功能劃分的更加清晰，有助于后面的維護(hù)。所以在一定程度上第二種方式是一個比較好的選擇！
當(dāng)然，話又說回來了，如果是一個很小的系統(tǒng)，功能也不是很繁雜，那么使用代理模式可能就顯得臃腫，不如第一種方式來的快捷。這就像一個三口之家，家務(wù)活全由家庭主婦或者一個保姆來完成是比較合理的，根本不需要雇上好幾個保姆層層代理:)
根據(jù)《Java與模式》書中對代理模式的分類，代理模式分為8種，這里將幾種常見的、重要的列舉如下：
1. 遠(yuǎn)程（Remote）代理：為一個位于不同的地址空間的對象提供一個局域代表對象。比如：你可以將一個在世界某個角落一臺機(jī)器通過代理假象成你局域網(wǎng)中的一部分。
2. 虛擬（Virtual）代理：根據(jù)需要將一個資源消耗很大或者比較復(fù)雜的對象延遲的真正需要時才創(chuàng)建。比如：如果一個很大的圖片，需要花費(fèi)很長時間才能顯示出來，那么當(dāng)這個圖片包含在文檔中時，使用編輯器或?yàn)g覽器打開這個文檔，這個大圖片可能就影響了文檔的閱讀，這時需要做個圖片Proxy來代替真正的圖片。
3. 保護(hù)（Protect or Access）代理：控制對一個對象的訪問權(quán)限。比如：在論壇中，不同的身份登陸，擁有的權(quán)限是不同的，使用代理模式可以控制權(quán)限（當(dāng)然，使用別的方式也可以實(shí)現(xiàn)）。
4. 智能引用（Smart Reference）代理：提供比對目標(biāo)對象額外的服務(wù)。比如：紀(jì)錄訪問的流量（這是個再簡單不過的例子），提供一些友情提示等等。
代理模式是一種比較有用的模式，從幾個類的“小結(jié)構(gòu)”到龐大系統(tǒng)的“大結(jié)構(gòu)”都可以看到它的影子。
三、結(jié)構(gòu)
代理模式中的“代理商”要想實(shí)現(xiàn)代理任務(wù)，就必須和被代理的“廠商”使用共同的接口（你可以想象為產(chǎn)品）。所以自然而然你會想到在Java中使用一個抽象類或者接口（推薦）來實(shí)現(xiàn)這個共同的接口。于是代理模式就有三個角色組成了：
1．抽象主題角色：聲明了真實(shí)主題和代理主題的共同接口。
2．代理主題角色：內(nèi)部包含對真實(shí)主題的引用，并且提供和真實(shí)主題角色相同的接口。
3．真實(shí)主題角色：定義真實(shí)的對象。
使用類圖來表示下三者間的關(guān)系如下：
當(dāng)然，圖上所示的是代理模式中的一個具體情況。而代理模式可以非常靈活的使用其他方式來實(shí)現(xiàn)，這樣就與圖上所示有很大的區(qū)別。
也許，現(xiàn)在你已經(jīng)對代理模式已經(jīng)有了一個宏觀的認(rèn)識了，下面我們來看看怎么實(shí)際的使用代理模式。
四、舉例
以論壇中已注冊用戶和游客的權(quán)限不同來作為第一個例子：已注冊的用戶擁有發(fā)帖，修改自己的注冊信息，修改自己的帖子等功能；而游客只能看到別人發(fā)的帖子，沒有其他權(quán)限。為了簡化代碼，更好的顯示出代理模式的骨架，我們這里只實(shí)現(xiàn)發(fā)帖權(quán)限的控制。 首先我們先實(shí)現(xiàn)一個抽象主題角色MyForum，里面定義了真實(shí)主題和代理主題的共同接口――發(fā)帖功能。
代碼如下：
public interface MyForum
{
public void AddFile();
}
這樣，真實(shí)主題角色和代理主題角色都要實(shí)現(xiàn)這個接口。其中真實(shí)的主題角色基本就是將這個接口的方法內(nèi)容填充進(jìn)來。所以在這里就不再贅述它的實(shí)現(xiàn)。我們把主要的精力放到關(guān)鍵的代理主題角色上。代理主題角色代碼大體如下：
public class MyForumProxy implements MyForum
{
private RealMyForum forum ;
private int permission ; //權(quán)限值
public MyForumProxy(int permission)
{
forum = new RealMyForum()
this.permission = permission ;
}
//實(shí)現(xiàn)的接口
public void AddFile()
{
//滿足權(quán)限設(shè)置的時候才能夠執(zhí)行操作
//Constants是一個常量類
if(Constants.ASSOCIATOR == permission)
{
forum.AddFile();
}
else
System.out.println("You are not a associator of MyForum ,please registe!");
}
}
這樣就實(shí)現(xiàn)了代理模式的功能。當(dāng)然你也可以在這個代理類上添加自己的方法來實(shí)現(xiàn)額外的服務(wù)，比如統(tǒng)計(jì)帖子的瀏覽次數(shù)，記錄用戶的登錄情況等等。
還有一個很常見的代理模式的使用例子就是對大幅圖片瀏覽的控制。在我們常見的網(wǎng)站上面瀏覽圖文的信息時，不知道你有沒有注意到，圖片位置放置的是經(jīng)過縮小的，當(dāng)有人要仔細(xì)的查看這個圖片時，可以通過點(diǎn)擊圖片來激活一個鏈接，在一個新的網(wǎng)頁打開要看的圖片 。這樣對于提高瀏覽速度是很有好處的，因?yàn)椴皇敲總€人都要去看仔細(xì)圖上的信息。這種情況就可以使用代理模式來全面實(shí)現(xiàn)。這里我將思路表述出來，至于實(shí)現(xiàn)由于工作原因，就不表述了，至于這種方式在B/S模式下的真實(shí)可行性，我沒有確認(rèn)過，只是憑空的想象。如果不是可行的方式，那這個例子可以放到一個C/S下來實(shí)現(xiàn)，這個是絕對沒有問題的，而且在很多介紹設(shè)計(jì)模式的書和文章中使用。兩種方式的實(shí)現(xiàn)有興趣的可以來嘗試一下。
我們在瀏覽器中訪問網(wǎng)頁時是調(diào)用的不是真實(shí)的裝載圖片的方法，而是在代理對象中的方法，在這個對象中，先使用一個線程向?yàn)g覽器裝載了一個縮小版的圖片，而在后臺使用另一個線程來調(diào)用真實(shí)的裝載大圖片的方法將圖片加載到本地，當(dāng)你要瀏覽這個圖片的時候，將其在新的網(wǎng)頁中顯示出來。當(dāng)然如果在你想瀏覽的時候圖片尚未加載成功，可以再啟動一個線程來顯示提示信息，直到加載成功。
這樣代理模式的功能就在上面體現(xiàn)的淋漓盡致――通過代理來將真實(shí)圖片的加載放到后臺來操作，使其不影響前臺的瀏覽。
五、總結(jié)
代理模式能夠協(xié)調(diào)調(diào)用者和被調(diào)用者，能夠在一定程度上降低系統(tǒng)的耦合度。不過一定要記住前面講的使用代理模式的條件，不然的話使用了代理模式不但不會有好的效果，說不定還會出問題的
jsp技術(shù)：基于Java的代理設(shè)計(jì)模式，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。
