|
|
直接與間接
人們對于復雜的軟件系統常常有一種處理手法，即增加一層間接層，從而對系統獲得一種更為靈活、滿足特定需求的解決方案。
假設A要訪問B三次。如果A和B是分布式中的兩個機器，那么A需要跨機器調用B三次就不是很好。如果在A和B之間加一個代理對象C，并且A和C處于同一個地址空間，即同一個機器。那么A和C之間通訊是非常高效的，現在A和C之間調用三次，到某個觸發點的時候，和B只需要一次的通訊，這樣性能就會好很多。這樣做還有一個好處，即A不需要再知道分布式通訊的內容了。
現實生活中，其實操作系統就是軟件和硬件之間的代理。
動機（Motivation）
在面向對象系統中，有些對象由于某種原因（比如對象創建的開銷很大，或者某些操作需要安全控制，或者需要進程外的訪問等），直接訪問會給使用者、或者系統結構帶來很多麻煩。如何在不失去透明操作對象的同時來管理/控制這些對象特有的復雜性？增加一層間接層是軟件開發中常見的解決方式。
意圖（Intent）
為其他對象提供一種代理以控制對這個對象的訪問。
——《設計模式》GoF
例說Proxy應用
HrSystem里面new的Employee對象將位于和HrSystem同樣的地址空間里面，但如果我們需要把Employee作為跨互聯網的調用，那么這樣的代碼就不適用了。改進后的代碼：
Employee的代理應該和Employee具有同樣的接口，它的實現很復雜。
其中，Employee類運行在InterNET遠端的一臺機器上，而EmployeeProxy運行在本地的Windows Forms上。這里代理的目的是為了屏蔽分布式通訊、WebService的細節。
結構（Structure）
其中Subject就是HrSystem，它本來是要直接調用RealSubject的。但是由于WebSerivce這種情況，它需要間接的通過Proxy調用RealSubject。
Proxy模式的幾個要點
“增加一層間接層”是軟件系統中對許多復雜問題的一種常見解決方法。在面向對象系統中，直接使用某些對象會來帶很多問題，作為間接層的Proxy對象便是解決這一問題的常用手段。具體Proxy設計模式的實現方法、實現粒度都相差很大，有些可能對單個對象做細粒度的控制，如copy-on-write技術，有些可能對組件模塊提供抽象代理層，在架構層次對對象做Proxy。
Proxy并不一定要求保持接口的一致性，只要能夠實現間接控制，有時候損及一些透明性是可以接受的。
WebService的一些例子：
代理對象MathService
客戶端
客戶端使用的是MathService類，這個類是在本地運行的。
另一個例子：Copy-on-Write
左邊是堆，這樣做是比較浪費內存的，因為系統中可能有很多字符串重復。目前大多數系統都是以下的做法：
但這樣字符串就不能更改了，例如如果要把s1改為大寫，那么必須要另起一個字符串變量：
C#當然也是允許對字符串更改的，不過不是string類型，而是StringBuilder類型。
這樣sb就可以被改變。StringBuilder的原理：
sb、sb2和sb3都指向同一個字符串，如果sb把里面內容改變，那么就會把hello拷貝到另一塊內存，再把內容進行更改。其實Copy-on-Write應該更準確地描述為Copy-on-Change。
StringBuilder其實就是一種代理，我們本意是想訪問字符串的，StringBuilder就是一種可變字符串的代理，而且StringBuilder也沒有和String保持接口的一致性。我們看看StringBuilder的源代碼：
注意Replace方法，當需要改變字符串的內容時，步驟是先new一個新的String，然后在更改新String的內容。但如果只有一個StringBuilder，那么就不需要拷貝到新的區域，而是直接在原來的String上修改。
it知識庫：C#面向對象設計模式縱橫談：Proxy 代理模式，轉載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
