設計模式系列之代理模式

作者：王波洋 2012-01-13 15:59:07

代理模式的定義：對其他對象提供一種代理以控制對這個對象的訪問。本文將通過一個食堂的案例給大家講講代理模式。

　　今天下班，同事們無聊中又聊到了食堂（怎么寫食堂？吃貨啊！），辦公區離食堂遠的同事老阮在大家你一句我一句的誘惑下，終于忍不住了決定不管在遠也要找時間去嘗嘗，但是因為上班不順路也不是很方便，就委托我們宿舍的老李同志幫忙第二天先去開卡充值，熱心腸的老李當然不會拒絕嘍。

　　1、模擬場景

　　有了這個前奏今天的主題就當然又有了，那么首先我們用代碼來實現上面的功能，首先來分析一下上面的場景：

　　①我們需要對卡片充值，所以需要一個卡片類，代碼如下：

　/// <summary> /// 卡片類  
　　/// </summary>  
　　public class Card  
　　{  
　//卡片名稱  
　　private string cardName = string.Empty;  
　　public string CardName  
　　{  
　　get 
　　{  
　　return cardName;  
　　}  
　　set 
　　{  
　　cardName = value;  
　　}  
　　}  
　　//構造方法  
　　public Card() { }  
　　public Card(string cName)  
　　{  
　　cardName = cName;  
　　}  
　　}

　　②接下來就是路遠的老阮，他的工卡需要去激活，代碼如下：

　　/// <summary> /// 老阮  
　　/// </summary>  
　　public class MrRuan  
　　{  
　　//他有一個工卡  
　　private Card myCard = new Card("mrRuan");  
　　public Card MyCard  
　　{  
　　get 
　　{  
　　return myCard;  
　　}  
　　}  
　　}

　　③接下來就是激活卡片當然要去柜臺了，記得在單例模式中已經將這個柜臺類實現了，那么我們就拿來用現成的吧，代碼如下：

　　/// <summary> /// 柜臺類  
　　/// </summary>  
　　public sealed class Counter  
　　{  
　　//在第一次調用類成員時，初始化唯一實例  
　　private static readonly Counter instance = new Counter();  
　　private Counter()  
　　{  
　　}  
　　//返回類型實例屬性  
　　public static Counter Instance  
　　{  
　　get 
　　{  
　　return instance;  
　　}  
　　}  
　　//激活工卡方法  
　　public void ActivationCard(Card card)  
　　{  
　　//激活工卡的過程  
　　Console.WriteLine("{0}的工卡激活成功!",card.CardName);  
　}  
　　}

　　④再就是幫助老軟第二天去激活卡片的老李，因為老李需要去激活卡片，所以包含激活卡片的操作，代碼如下：

　　/// <summary> /// 熱心腸的老李  
　　/// </summary>  
　　public class MrLi  
　　{  
　　//激活工卡方法  
　　public void ActivationCard(Card card)  
　　{  
　　Counter.Instance.ActivationCard(card);  
　　}  
　　}

　　⑤類型都抽象出來之后當然就是第二天去激活卡片啦，主函數調用代碼如下：

　　static void Main(string[] args)  
　　{  
　　//實例化老阮  
　　MrRuan ruan = new MrRuan();  
　　//實例化老李  
　　MrLi li = new MrLi();  
　　//將卡片給老李，老李負責去激活  
　　li.ActivationCard(ruan.MyCard);  
　　}

　　仔細想了一下，這樣一來老李也就成了柜臺開卡的代理人了，以后別人也可以委托他去幫忙激活卡片了，這不就是活生生的代理模式嗎？

　　這時你要問了，那代理模式具體的定義是什么呀？到底什么是代理模式下？別著急繼續往下看吧。

　　2、代理模式

　　代理（Proxy）模式定義：為其他對象提供一種代理以控制對這個對象的訪問。類圖如下：

　　這時我們發現了多了一個接口ICounter,那么實現了接口的代理類與具體類的代碼如下：

　　/// <summary> /// 柜臺類也就是具體類提供的功能規則  
　　/// </summary>  
　　public interface ICounter  
　　{  
　void ActivationCard(Card card);  
　　}  
　　/// <summary> /// 熱心腸的老李  
　　/// </summary>  
　　public class MrLi : ICounter  
　　{  
　　//激活工卡方法  
　　public void ActivationCard(Card card)  
　　{  
　　Counter.Instance.ActivationCard(card);  
　　}  
　　}  
　　/// <summary> /// 柜臺類  
　　/// </summary>  
　　public sealed class Counter : ICounter  
　　{  
　　//在第一次調用類成員時，初始化唯一實例  
　　private static readonly Counter instance = new Counter();  
　　private Counter()  
　　{  
　　}  
　　//返回類型實例屬性  
　　public static Counter Instance  
　　{  
　　get 
　　{  
　　return instance;  
　　}  
　　}  
　　//激活工卡方法  
　　public void ActivationCard(Card card)  
　　{  
　　//激活工卡的過程  
　　Console.WriteLine("{0}的工卡激活成功!",card.CardName);  
　　}  
　　}

　　那么這個接口有什么用呢？

　　在面向對象設計中，對象之間需要進行交互和通信。例如：上面的代理類MrLi調用了具體類柜臺類counter的激活卡片的方法（ActiviationCard），那么這個時候代理類MrLi不在代理counter柜臺的激活卡片功能了，而是去另一個counterNew的柜臺去激活，但是counterNew柜臺激活卡片的方法是（CounterActiviationCard），怎么辦？我們需要去修改調用counter的類，那么如何降低耦合性呢？當然就是將接口和實現分離開來，這樣組件間和日志對象之間的依賴就是基于接口，而不是實現！

　　例如：目前MrLi與counter之間的調用如下：

　　/// <summary> /// 熱心腸的老李  
　　/// </summary>  
　　public class MrLi  
　　{  
　　//激活工卡方法  
　　public void ActivationCard(Card card)  
　　{  
　Counter.Instance.ActivationCard(card);  
　　}  
　　}  
　　那么如果需要加入新的柜臺類（counterNew），它的激活方法叫（CounterActivationCard），代碼如下：  
　　/// <summary> /// 新的柜臺類  
　　/// </summary>  
　　public sealed class NewCounter  
　　{  
　　//在第一次調用類成員時，初始化唯一實例  
　　private static readonly NewCounter instance = new NewCounter();  
　　private NewCounter()  
　　{  
　}  
　　//返回類型實例屬性  
　　public static NewCounter Instance  
　{  
　　get 
　　{  
　　return instance;  
　　}  
　　}  
　　//激活工卡方法  
　　public void CounterActivationCard(Card card)  
　　{  
　　//激活工卡的過程  
　　Console.WriteLine("{0}的工卡激活成功!", card.CardName);  
　　}  
　　}

　　這樣兩個類就緊密的耦合在一起了，若Counter類改變，那么MrLi類也不得不改變，這時我們如果想使用新的柜臺類（NewCounter），也需要修改調用者本身。

　　所以我們需要使用接口分離實現。代碼如下：

　　/// <summary> /// 柜臺類也就是具體類提供的功能規則  
　　/// </summary>  
　　public interface ICounter  
　　{  
　　void ActivationCard(Card card);  
　　}  
　/// <summary> /// 熱心腸的老李  
　　/// </summary>  
　　public class MrLi : ICounter  
　　{  
　　//激活工卡方法  
　　public void ActivationCard(Card card)  
　　{  
　　Counter.Instance.ActivationCard(card);  
　　}  
　　}  
　　/// <summary> /// 柜臺類  
　　/// </summary>  
　　public sealed class Counter : ICounter  
　　{  
　　//在第一次調用類成員時，初始化唯一實例  
　　private static readonly Counter instance = new Counter();  
　　private Counter()  
　　{  
　　}  
　　//返回類型實例屬性  
　　public static Counter Instance  
　　{  
　　get 
　　{  
　　return instance;  
　　}  
　　}  
　　//激活工卡方法  
　　public void ActivationCard(Card card)  
　　{  
　　//激活工卡的過程  
　　Console.WriteLine("{0}的工卡激活成功!",card.CardName);  
　　}  
　　}  
　　/// <summary> /// 新的柜臺類  
　　/// </summary>  
　　public sealed class NewCounter : ICounter  
　　{  
　　//在第一次調用類成員時，初始化唯一實例  
　　private static readonly NewCounter instance = new NewCounter();  
　　private NewCounter()  
　　{  
　　}  
　　//返回類型實例屬性  
　　public static NewCounter Instance  
　　{  
　　get 
　　{  
　　return instance;  
　　}  
　　}  
　　//激活工卡方法  
　　public void ActivationCard(Card card)  
　　{  
　　//激活工卡的過程  
　　Console.WriteLine("{0}的工卡激活成功!", card.CardName);  
　　}  
　　}

　　有了接口的約束，所有柜臺類都遵循了這個約束將激活卡片的方法統一成（ActivationCard），那么在將來切換對象的時候都可以以一種統一的調用方式去無縫的卻換。

　　這時細心的朋友還會說，Mr.Li的ActivationCard方法中調用的是具體的counter類型如果換成Newcounter，還是要去修改它的代碼，你現在只能是不用去修改調用方法了而已，想的好，還記得我們當時的工廠模式嗎？它的好處不就是降低耦合嗎？為什么不用？

　　那么加入工廠類（CounterProvider），在修改一下MrLi的調用使它的調用依賴于抽象接口而不是具體的實現，代碼如下：

　　/// <summary> /// 熱心腸的老李  
　　/// </summary>  
　　public class MrLi : ICounter  
　　{  
　　//激活工卡方法  
　　public void ActivationCard(Card card)  
　　{  
　ICounter counter = CounterProvider.GetCounter();  
　　counter.ActivationCard(card);  
　}  
　　}  
　　/// <summary> /// 柜臺類工廠  
　　/// </summary>  
　public class CounterProvider  
　　{  
　public static ICounter GetCounter()  
　{  
　　ICounter counter = null 
　　//從配置文件確定實例化那個柜臺類  
　　if (ReadConfig)  
　　{  
　　counter = Counter.Instance;  
　　}  
　　else 
　　{  
　　counter = NewCounter.Instance;  
　　}  
　　}  
　　}

　　這樣我們就徹底的實現了代理模式，并且詮釋了如何使用接口的好處和靈活組合模式與靈活理解模式與使用。

　　3、應用場景

　　那么代理模式的幾種使用場景我們來看一看：

　　①遠程代理：為一個對象在不同地址空間提供局部代表。這樣可以隱藏一個對象存在于不同地址空間的事實，例如：老阮(MrRuan)在地點A，老李在地點B，餐廳柜臺也在地點B，那么老李和老軟住在一起（都在地點A住），那么老李就是餐廳（地點B）在老軟與老李住處（地點A）的代表。

　　②虛擬代理：是根據需要創建開銷很大的對象。通過它來存放實例化需要很長時間的真是對象，例如：老阮(MrRuan)在地點A，到餐廳柜臺（地點B），因為距離遠卻是很費勁，而老李剛好在這里（地點B）上班，所以讓老李去辦是很可行的辦法。（不太恰當）

　　③安全代理：用來控制真是對象訪問時的權限，例如：老阮跟餐廳的柜臺MM剛分手不方便去辦理，所以需要借助老李去完成事項的辦理。

　　④智能代理：是指當調用真是的對象時，代理去處理另外一些事情，例如：老李幫助老阮辦理卡片激活時，順便說說老阮的好話，讓她倆能夠和好。

原文鏈接：http://www.cnblogs.com/doubleliang/archive/2012/01/12/2321092.html

【編輯推薦】

JAVA設計模式:工廠模式之簡單工廠
從理發店流程抽象設計模式中的組合模式
大話惱人的那些設計模式
淺談設計模式五大原則
JavaScript設計模式深入分析

責任編輯：彭凡來源：博客園

代理模式