一、引子

　　我們?nèi)タ萍际袌鰹樽约旱臋C器添加點奢侈的配件，很多DIYer都喜歡去找代理商，因為在代理商那里拿到的東西不僅質(zhì)量有保證，而且價格和售后服務上都會好很多。客戶通過代理商得到了自己想要的東西，而且還享受到了代理商額外的服務；而生產(chǎn)廠商通過代理商將自己的產(chǎn)品推廣出去，而且可以將一些銷售服務的任務交給代理商來完成（當然代理商要和廠商來共同分擔風險，分配利潤），這樣自己就可以花更多的心思在產(chǎn)品的設計和生產(chǎn)上了。

　　在美國，任何企業(yè)的產(chǎn)品要想拿到市場上去賣就必須經(jīng)過代理商這一個環(huán)節(jié)，否則就是非法的。看來代理商在商業(yè)運作中起著很關鍵的作用。 不小心把話題扯遠了，回過頭來，那么在我們的面向?qū)ο蟮某绦蛟O計中，會不會有代理商這樣的角色呢？來看這篇文章的人肯定不會說：沒有！

　　那么就跟著這篇文章來看看代理模式的奇妙吧。

　　二、定義和分類

　　代理模式在設計模式中的定義就是：為其他對象提供一種代理以控制對這個對象的訪問。說白了就是，在一些情況下客戶不想或者不能直接引用一個對象，而代理對象可以在客戶和目標對象之間起到中介作用，去掉客戶不能看到的內(nèi)容和服務或者增添客戶需要的額外服務。

　　那么什么時候要使用代理模式呢？在對已有的方法進行使用的時候出現(xiàn)需要對原有方法進行改進或者修改，這時候有兩種改進選擇：修改原有方法來適應現(xiàn)在的使用方式，或者使用一個“第三者”方法來調(diào)用原有的方法并且對方法產(chǎn)生的結(jié)果進行一定的控制。第一種方法是明顯違背了“對擴展開放、對修改關閉”（開閉原則），而且在原來方法中作修改可能使得原來類的功能變得模糊和多元化（就像現(xiàn)在企業(yè)多元化一樣），而使用第二種方式可以將功能劃分的更加清晰，有助于后面的維護。所以在一定程度上第二種方式是一個比較好的選擇！

　　當然，話又說回來了，如果是一個很小的系統(tǒng)，功能也不是很繁雜，那么使用代理模式可能就顯得臃腫，不如第一種方式來的快捷。這就像一個三口之家，家務活全由家庭主婦或者一個保姆來完成是比較合理的，根本不需要雇上好幾個保姆層層代理:)

　　根據(jù)《Java與模式》書中對代理模式的分類，代理模式分為8種，這里將幾種常見的、重要的列舉如下：

　　1. 遠程（Remote）代理：為一個位于不同的地址空間的對象提供一個局域代表對象。比如：你可以將一個在世界某個角落一臺機器通過代理假象成你局域網(wǎng)中的一部分。

　　2. 虛擬（Virtual）代理：根據(jù)需要將一個資源消耗很大或者比較復雜的對象延遲的真正需要時才創(chuàng)建。比如：如果一個很大的圖片，需要花費很長時間才能顯示出來，那么當這個圖片包含在文檔中時，使用編輯器或瀏覽器打開這個文檔，這個大圖片可能就影響了文檔的閱讀，這時需要做個圖片Proxy來代替真正的圖片。

　　3. 保護（Protect or Access）代理：控制對一個對象的訪問權限。比如：在論壇中，不同的身份登陸，擁有的權限是不同的，使用代理模式可以控制權限（當然，使用別的方式也可以實現(xiàn)）。

　　4. 智能引用（Smart Reference）代理：提供比對目標對象額外的服務。比如：紀錄訪問的流量（這是個再簡單不過的例子），提供一些友情提示等等。

　　代理模式是一種比較有用的模式，從幾個類的“小結(jié)構(gòu)”到龐大系統(tǒng)的“大結(jié)構(gòu)”都可以看到它的影子。

　　三、結(jié)構(gòu)

　　代理模式中的“代理商”要想實現(xiàn)代理任務，就必須和被代理的“廠商”使用共同的接口（你可以想象為產(chǎn)品）。所以自然而然你會想到在java中使用一個抽象類或者接口（推薦）來實現(xiàn)這個共同的接口。于是代理模式就有三個角色組成了：

　　1．抽象主題角色：聲明了真實主題和代理主題的共同接口。

　　2．代理主題角色：內(nèi)部包含對真實主題的引用，并且提供和真實主題角色相同的接口。

　　3．真實主題角色：定義真實的對象。

　　使用類圖來表示下三者間的關系如下：


　　當然，圖上所示的是代理模式中的一個具體情況。而代理模式可以非常靈活的使用其他方式來實現(xiàn)，這樣就與圖上所示有很大的區(qū)別。

　　也許，現(xiàn)在你已經(jīng)對代理模式已經(jīng)有了一個宏觀的認識了，下面我們來看看怎么實際的使用代理模式。

　　四、舉例

　　以論壇中已注冊用戶和游客的權限不同來作為第一個例子：已注冊的用戶擁有發(fā)帖，修改自己的注冊信息，修改自己的帖子等功能；而游客只能看到別人發(fā)的帖子，沒有其他權限。為了簡化代碼，更好的顯示出代理模式的骨架，我們這里只實現(xiàn)發(fā)帖權限的控制。 首先我們先實現(xiàn)一個抽象主題角色MyForum，里面定義了真實主題和代理主題的共同接口——發(fā)帖功能。

　　代碼如下：

　　public interface MyForum

　　{

　　public void AddFile();

　　}

　　這樣，真實主題角色和代理主題角色都要實現(xiàn)這個接口。其中真實的主題角色基本就是將這個接口的方法內(nèi)容填充進來。所以在這里就不再贅述它的實現(xiàn)。我們把主要的精力放到關鍵的代理主題角色上。代理主題角色代碼大體如下：

　　public class MyForumProxy implements MyForum
　　{
　　private RealMyForum forum ;
　　private int permission ; //權限值

　　public MyForumProxy(int permission)
　　{
　　forum = new RealMyForum()
　　this.permission = permission ;
　　}

　　//實現(xiàn)的接口

　　public void AddFile()
　　{
　　//滿足權限設置的時候才能夠執(zhí)行操作
　　//Constants是一個常量類
　　if(Constants.ASSOCIATOR == permission)
　　{
　　　forum.AddFile();
　　}
　　else
　　　System.out.println("You are not a associator of MyForum ,please registe!");
　　}
　　}

　　這樣就實現(xiàn)了代理模式的功能。當然你也可以在這個代理類上添加自己的方法來實現(xiàn)額外的服務，比如統(tǒng)計帖子的瀏覽次數(shù)，記錄用戶的登錄情況等等。

　　還有一個很常見的代理模式的使用例子就是對大幅圖片瀏覽的控制。在我們常見的網(wǎng)站上面瀏覽圖文的信息時，不知道你有沒有注意到，圖片位置放置的是經(jīng)過縮小的，當有人要仔細的查看這個圖片時，可以通過點擊圖片來激活一個鏈接，在一個新的網(wǎng)頁打開要看的圖片 。這樣對于提高瀏覽速度是很有好處的，因為不是每個人都要去看仔細圖上的信息。這種情況就可以使用代理模式來全面實現(xiàn)。這里我將思路表述出來，至于實現(xiàn)由于工作原因，就不表述了，至于這種方式在B/S模式下的真實可行性，我沒有確認過，只是憑空的想象。如果不是可行的方式，那這個例子可以放到一個C/S下來實現(xiàn)，這個是絕對沒有問題的，而且在很多介紹設計模式的書和文章中使用。兩種方式的實現(xiàn)有興趣的可以來嘗試一下。

　　我們在瀏覽器中訪問網(wǎng)頁時是調(diào)用的不是真實的裝載圖片的方法，而是在代理對象中的方法，在這個對象中，先使用一個線程向瀏覽器裝載了一個縮小版的圖片，而在后臺使用另一個線程來調(diào)用真實的裝載大圖片的方法將圖片加載到本地，當你要瀏覽這個圖片的時候，將其在新的網(wǎng)頁中顯示出來。當然如果在你想瀏覽的時候圖片尚未加載成功，可以再啟動一個線程來顯示提示信息，直到加載成功。

　　這樣代理模式的功能就在上面體現(xiàn)的淋漓盡致——通過代理來將真實圖片的加載放到后臺來操作，使其不影響前臺的瀏覽。

　　五、總結(jié)

　　代理模式能夠協(xié)調(diào)調(diào)用者和被調(diào)用者，能夠在一定程度上降低系統(tǒng)的耦合度。不過一定要記住前面講的使用代理模式的條件，不然的話使用了代理模式不但不會有好的效果，說不定還會出問題的