代理模式的目地是為物件提供一種代理以控制對這個物件的訪問，為什么會出現“通過一個代理物件，控制其他物件訪問目標物件”這種場景，而不知直接new()出一個物件直接使用呢？這是因為在有些場景下物件的訪問比較復雜，且需要一些額外的控制，這時如果直接new()出實體，并在呼叫端處理這些繁雜的細節，會增加系統的耦合，類似的場景有很多，比如遠程訪問、資料庫訪問、權限校驗、負載均衡等等，
GOF對外觀模式的描述為：
Provide a surrogate or placeholder for another object to control accessto it...
— Design Patterns : Elements of Reusable Object-Oriented Software
UML類圖:
代理類本身也實作了ISubject介面，但在具體呼叫時，它會把請求轉向一個RealSubject物件進行真正的處理，
代碼實作:
public interface ISubject
{
string Request();
}
public class RealSubject : ISubject
{
public string Request()
{
return "From real subject";
}
//這里使用Singleton的目地是模擬復雜性，比如客戶程式并不知道如何使用遠端的具體型別
private static ISubject singleton = new RealSubject();
private RealSubject() { }
public static ISubject GetInstance()
{
return singleton;
}
}
public class Proxy : ISubject
{
public string Request()
{
//預處理
var result= RealSubject.GetInstance().Request();
//后處理
return result;
}
}
在代碼示例中，使用Singleton模擬物件訪問的復雜性，然后使用代理封裝了這種復雜性，同時對訪問的控制可以在預處理、后處理的部分擴展，
使用代理物件需要注意的幾個問題
- 引入代理物件并不應該增加客戶程式的復雜性，按照依賴倒置的原則，客戶程式需要知道的也只是目標物件的抽象介面，因此相應的代理物件也就應該實作這個介面，否則等于變相向客戶程式引入新的復雜性，
- 代理的目的是控制客戶程式對目標物件的訪問，因此代理必須可以直接或間接地知道目標型別在哪，以及如何訪問，
- 代理類不必知道具體的目標型別，很多時候它只要能夠按照與客戶程式統一的約定，提供一個具有抽象特征的型別即可，代理類也只依賴抽象型別，至于具體目標型別，可以組合使用創建型模式來實作，
代理模式的優點
- 職責清晰，具體目標型別只需要實作實際的業務邏輯，而不用關心其他非本職責的事務，通過后期的代理完成這些事務，附帶的結果就是編程簡潔清晰，
- 代理物件可以在客戶端和目標物件之間起到中介的作用，起到保護目標物件的作用，
- 高擴展性，
代理模式的缺點
- 代理模式會造成系統設計中類的數目的增加，
- 由于在客戶端和真實主題之間增加了代理物件，因此有些型別的代理模式可能會造成請求的處理速度變慢，
- 增加了系統的復雜度，
參考書籍：
王翔著 《設計模式——基于C#的工程化實作及擴展》
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/3112.html
標籤：設計模式
上一篇：設計模式(11) 享元模式