解析proxy代理模式在Ruby设计模式开发中的运用

我们都知道设计模式是为了弥补语言的不足才出现的，如果语言强大，那么需要设计的模式就会很少，我们在很多时候使用Ruby语言提供特性的时候，其实不知不觉已经在设计模式了，接下来，爱站技术频道小编就为大家带来解析proxy代理模式在Ruby设计模式开发中的运用，一起看看吧！

代理模式
Proxy代理模式是一种结构型设计模式，主要解决的问题是：在直接访问对象时带来的问题，比如说：要访问的对象在远程的机器上。在面向对象系统中，有些对象由于某些原因（比如对象创建开销很大，或者某些操作需要安全控制，或者需要进程外的访问），直接访问会给使用者或者系统结构带来很多麻烦，我们可以在访问此对象时加上一个对此对象的访问层。如下图：

  比如说C和A不在一个服务器上，A要频繁的调用C，我们可以在A上做一个代理类Proxy，把访问C的工作交给Proxy，这样对于A来说，就好像在直接访问C的对象。在对A的开发中我们可以把注意力完全放在业务的实现上。
GoF《设计模式》中说道：为其他对象提供一种代理以控制这个对象的访问。
Proxy模式的结构：

通过代理模式以客户透明的形式动态的为目标对象加以行为控制

实例

class BankAccount
 
 def deposit
  p "store the money"
 end
 
end

class 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.new
bankAccount.deposit
proxy = Proxy.new bankAccount
proxy.deposit

  Proxy模式的要点：
1、“增加一层间接层”是软件系统中对许多负责问题的一种常见解决方法。在面向对象系统中，直接使用某些对象会带来很多问题，作为间接层的proxy对象便是解决这一问题的常用手段。
在我们日常的工作中也常常用到代理模式，比如对于三层结构或者N- tiers结构中DAL数据访问层，它把对数据库的访问进行封装。BLL业务层的开发者只是调用DAL中的方法来获得数据。
再比如前一段时间看了看AOP和Remoting方面的资料，对于跨越应用程序域的访问，要为客户应用程序提供一个TransparentProxy（透明代理），客户程序实际上是通过访问这个代理来访问实际的类型对象。
2、具体proxy设计模式的实现方法、实现粒度都相差很大，有些可能对单个对象作细粒度的控制，有些可能对组件模块提供抽象代理层，在架构层次对对象作proxy。
3、proxy并不一定要求保持接口的一致性，只要能够实现间接控制，有时候损及一些透明性是可以接受的。例如上面的那个例子，代理类型ProxyClass和被代理类型LongDistanceClass可以不用继承自同一个接口，正像GoF《设计模式》中说的：为其他对象提供一种代理以控制这个对象的访问。代理类型从某种角度上讲也可以起到控制被代理类型的访问的作用。

以上就是爱站技术频道小编介绍的解析proxy代理模式在Ruby设计模式开发中的运用，程序员一定要尽可能的全程跟进项目，而且在使用之前别忘记测试哦。