为什么要使用代理模式

代理这个词大家肯定已经非常熟悉，因为现实中接触的很多，其实现实中的东西恰恰可以非常形象和直观地反映出模式的抽象过程以及本质。现在房子不是吵得热火朝天吗？我们就以房子为例，来拨开代理的面纱。

假设你有一套房子要卖，一种方法是你直接去网上发布出售信息，然后直接带要买房子的人来看房子、过户等一直到房子卖出去，但是可能你很忙，你没有时间去处理这些事情，所以你可以去找中介，让中介帮你处理这些琐碎事情，中介实际上就是你的代理。本来是你要做的事情，现在中介帮助你一一处理，对于买方来说跟你直接交易跟同中介直接交易没有任何差异，买方甚至可能觉察不到你的存在，这实际上就是代理的一个最大好处。

接下来我们再深入考虑一下为什么你不直接买房子而需要中介？其实一个问题恰恰解答了什么时候该用代理模式的问题。

原因一：你可能在外地上班，买房子的人没法找到你直接交易。

对应到我们程序设计的时候就是：客户端无法直接操作实际对象。那么为什么无法直接操作？一种情况是你需要调用的对象在另外一台机器上，你需要跨越网络才能访问，如果让你直接coding去调用，你需要处理网络连接、处理打包、解包等等非常复杂的步骤，所以为了简化客户端的处理，我们使用代理模式，在客户端建立一个远程对象的代理，客户端就象调用本地对象一样调用该代理，再由代理去跟实际对象联系，对于客户端来说可能根本没有感觉到调用的东西在网络另外一端，这实际上就是Web Service的工作原理。另一种情况虽然你所要调用的对象就在本地，但是由于调用非常耗时，你怕影响你正常的操作，所以特意找个代理来处理这种耗时情况，一个最容易理解的就是Word里面装了很大一张图片，在word被打开的时候我们肯定要加载里面的内容一起打开，但是如果等加载完这个大图片再打开Word用户等得可能早已经跳脚了，所以我们可以为这个图片设置一个代理，让代理慢慢打开这个图片而不影响Word本来的打开的功能。申明一下我只是猜可能Word是这么做的，具体到底怎么做的，俺也不知道。

原因二：你不知道怎么办过户手续，或者说除了你现在会干的事情外，还需要做其他的事情才能达成目的。

对应到我们程序设计的时候就是：除了当前类能够提供的功能外，我们还需要补充一些其他功能。最容易想到的情况就是权限过滤，我有一个类做某项业务，但是由于安全原因只有某些用户才可以调用这个类，此时我们就可以做一个该类的代理类，要求所有请求必须通过该代理类，由该代理类做权限判断，如果安全则调用实际类的业务开始处理。可能有人说为什么我要多加个代理类？我只需要在原来类的方法里面加上权限过滤不就完了吗？在程序设计中有一个类的单一性原则问题，这个原则很简单，就是每个类的功能尽可能单一。为什么要单一，因为只有功能单一这个类被改动的可能性才会最小，就拿刚才的例子来说，如果你将权限判断放在当前类里面，当前这个类就既要负责自己本身业务逻辑、又要负责权限判断，那么就有两个导致该类变化的原因，现在如果权限规则一旦变化，这个类就必需得改，显然这不是一个好的设计。

好了，原理的东西已经讲得差不多了，要是再讲个没完可能大家要扔砖头了。呵呵，接下来就看看怎么来实现代理。

代理模式的实现：

其实代理模式还是很容易实现的，随便举个例子，比如你有一个类负责返回员工的薪资信息，如下：

 

Java代码 复制代码
  1. public class BusinessClass   
  2.   
  3. {   
  4.   
  5. public double GetPayroll(string employee)   
  6.   
  7. {   
  8.   
  9. //返回薪资结果   
  10.   
  11. return 1000;   
  12.   
  13. }   
  14.   
  15. }   
  16.   
  17. 由于薪资信息是公司的机密信息，不是谁都能调用查看，所以我们为该类做一个代理来做用户身份的验证，代码如下：   
  18.   
  19. public class Proxy   
  20.   
  21. {   
  22.   
  23. private BusinessClass bc;   
  24.   
  25. public Proxy(BusinessClass bc)   
  26.   
  27. {   
  28.   
  29. this.bc=bc;   
  30.   
  31. }   
  32.   
  33. public double GetPayroll(string user)   
  34.   
  35. {   
  36.   
  37. //判断user权限   
  38.   
  39. //如果不符合返回null,或者抛出异常   
  40.   
  41. if( IsManage(user) )   
  42.   
  43. {   
  44.   
  45. return bc.GetPayroll(”张三”);   
  46.   
  47. }   
  48.   
  49. throw new Exception(”你没有该权限。”);   
  50.   
  51. }   
  52.   
  53. }   
  54.   
  55. 注意：代理类需要使用被代理类来做业务逻辑，所以代理类需要包含被代理类的实例，这跟适配器模式是一样的。   
  56.   
  57. 到目前为止目的其实已经达到了，但是现实中我们常常会再为代理类和被代理类抽象出一个公共接口，如下：   
  58.   
  59. public interface IBusinessClass   
  60.   
  61. {   
  62.   
  63. double GetPayroll(string user);   
  64.   
  65. }  

 

      很多人肯定会问为什么要抽象这个接口呢？其实抽象接口有一个最大的原因就是约束双方的行为！什么意思呢？其实就是我逼迫Proxy必须实现某些方法，而这些方法恰恰是对外公开的主要业务方法。当然也可以靠程序员自律，但是多一个约束总归是好的，至少如果没有实现指定方法我们可以在编译期就发现错误，总比执行时才能发现错误要好。另外的原因可能都得归结到使用接口的好处上去了，这里不再赘述，自己去查接口的文章介绍了。

posted @ 2010-02-05 17:48  Silver.Lee  阅读(7684)  评论(2)  编辑  收藏  举报