解析proxy代理模式在Ruby設計模式開發中的運用_ruby專題

代理模式
Proxy代理模式是一種結構型設計模式，主要解決的問題是：在直接存取對象時帶來的問題，比如說：要訪問的對象在遠端機器上。在物件導向系統中，有些對象由於某些原因（比如對象建立開銷很大，或者某些操作需要安全控制，或者需要進程外的訪問），直接存取會給使用者或者系統結構帶來很多麻煩，我們可以在訪問此對象時加上一個對此對象的訪問層。如下圖：

 

  比如說C和A不在一個伺服器上，A要頻繁的調用C，我們可以在A上做一個代理類Proxy，把訪問C的工作交給Proxy，這樣對於A來說，就好像在直接存取C的對象。在對A的開發中我們可以把注意力完全放在業務的實現上。
GoF《設計模式》中說道：為其他對象提供一種代理以控制這個對象的訪問。
Proxy模式的結構：

通過代理模式以客戶透明的形式動態為目標對象加以行為控制

執行個體

class BankAccount  def deposit  p "store the money" end endclass Proxy  attr_accessor :bankAccount  def initialize bankAccount  @bankAccount = bankAccount end  def deposit  @bankAccount.deposit end end

 建立銀行賬戶類，再建立代理類，代理類彙總銀行賬戶類，提供相同的行為結構，對客戶來說代理類就是一個偽賬戶類，對代理類做操作的時候，其實就是在對真實的銀行類做操作。
加以行為控制：

class Proxy  attr_accessor :bankAccount  def initialize bankAccount  @bankAccount = bankAccount end  def deposit  check_something  @bankAccount.deposit end  def check_something  #do some checking code end end

 這樣我們就可以在對調用目標對象的同時增加控制碼，但是這一切都是以透明的方式展示給客戶，對客戶來說就跟調用普通的BankAccount對象方法一樣

bankAccount = BankAccount.newbankAccount.depositproxy = Proxy.new bankAccountproxy.deposit

  Proxy模式的要點：
1、“增加一層間接層”是軟體系統中對許多負責問題的一種常見解決方案。在物件導向系統中，直接使用某些對象會帶來很多問題，作為間接層的proxy對象便是解決這一問題的常用手段。
在我們日常的工作中也常常用到代理模式，比如對於三層結構或者N- tiers結構中DAL資料訪問層，它把對資料庫的訪問進行封裝。BLL業務層的開發人員只是調用DAL中的方法來獲得資料。
再比如前一段時間看了看AOP和Remoting方面的資料，對於跨越應用程式定義域的訪問，要為客戶應用程式提供一個TransparentProxy（透明代理），客戶程式實際上是通過訪問這個代理來訪問實際的類型對象。
2、具體proxy設計模式的實現方法、實現粒度都相差很大，有些可能對單個對象作細粒度的控制，有些可能對組件模組提供抽象代理層，在架構層次對對象作proxy。
3、proxy並不一定要求保持介面的一致性，只要能夠實現間接控制，有時候損及一些透明性是可以接受的。例如上面的那個例子，代理類型ProxyClass和被代理類型LongDistanceClass可以不用繼承自同一個介面，正像GoF《設計模式》中說的：為其他對象提供一種代理以控制這個對象的訪問。代理類型從某種角度上講也可以起到控制被代理類型的訪問的作用。