[转]《设计模式之禅》样章连载5：代理模式的定义及应用

转自：http://student.youkuaiyun.com/space.php?uid=259146&do=blog&id=25843

 

12.2  代理模式的定义

代理模式(Proxy Pattern)是一个使用率非常高的模式，其定义如下：

provide a surrogate or placeholder for another object to control access to it. 为其他对象提供一种代理以控制对这个对象的访问。

代理模式的通用类图如图12-3所示。

<!--[if !supportLists]-->图12-3        <!--[endif]-->代理模式的通用类图

代理模式也叫做委托模式，它是一项基本设计技巧，许多其他的模式，如状态模式、策略模式、访问者模式本质上是在更特殊的场合采用了委托模式，而且在日常的应用中，代理模式可以提供非常好的访问控制，在一些著名开源软件中也经常见到它的身影，如Struts2的Form元素映射就采用了代理模式（准确的说是动态代理模式）。我们先看一下类图中的三个角色的定义：

• <!--[if !supportLists]-->Subject抽象主题角色

抽象主题类可以是抽象类也可以是接口，是一个最普通的业务类型定义，无特殊要求。

• <!--[if !supportLists]-->RealSubject 具体主题角色

也叫做被委托角色、被代理角色，它才是冤大头，是业务逻辑的具体执行者。

• <!--[if !supportLists]-->Proxy 代理主题角色

也叫做委托类、代理类，它负责对真实角色的应用，把所有抽象主题类定义的方法限制委托给真实主题角色实现，并且在真实主题角色处理完毕前后做预处理和善后处理工作。

我们首先来看Subject抽象主题类的通用源码，如代码清单12-6所示。

<!--[if !supportLists]-->代码清单12-1              <!--[endif]-->抽象主题类

public interface Subject { 

     //定义一个方法

     public void request();

}

在接口中我们定义了一个方法request来作为方法的代表，RealSubject对它进行实现，如代码清单12-7所示。

<!--[if !supportLists]-->代码清单12-2              <!--[endif]-->真实主题类

public class RealSubject implements Subject {     

     //实现方法

     public void request() {

            //业务逻辑处理

     }

}

RealSubject是一个正常的业务实现类，代理模式的核心就在代理类上，如代码清单12-8所示。

<!--[if !supportLists]-->代码清单12-3              <!--[endif]-->代理类

public class Proxy implements Subject {

     //要代理哪个实现类

     private Subject subject = null;      

     //默认被代理者

     public Proxy(){

            this.subject = new Proxy();

     }

     //通过构造函数传递代理者

     public Proxy(Object...objects ){

<!--[if !supportEmptyParas]--> <!--[endif]-->

     }

     //实现接口中定义的方法

     public void request() {

            this.before();

            this.subject.request();

            this.after();

     }

     //预处理

     private void before(){

            //do something

     }

     //善后处理

     private void after(){

            //do something

     }

}

看到这里，大家别惊讶，为什么会出现before和after方法，继续看下去，这是一个“引子”，能够引出一个崭新的编程模式。

一个代理类可以代理多个被委托者或被代理者，因此一个代理类具体代理哪个真实主题角色，是由场景类决定的，当然，最简单的情况就是一个主题类一个代理类，这是最简洁的代理模式。在通常情况下，一个接口只需要一个代理类就可以了，具体代理哪个实现类由高层模块来决定，也就是在代理类的构造函数中传递被代理者，例如我们可以在代理类Proxy中增加如代码清单12-9所示的构造函数。

<!--[if !supportLists]-->代码清单12-4              <!--[endif]-->代理的构造函数

      public Proxy(Subject _subject){

            this.subject = _subject;

     }

你要代理谁，产生该代理的实例，然后把被代理者传递进来，该模式在实际的项目应用中比较广泛。

<!--[if !supportLists]-->12.3  <!--[endif]-->代理模式的应用

12.3.1 代理模式的优点

• <!--[if !supportLists]-->职责清晰

真实的角色就是实现实际的业务逻辑，不用关心其他非本职责的事务，通过后期的代理完成一件完成事务，附带的结果就是编程简洁清晰。

• <!--[if !supportLists]--><!--[endif]-->高扩展性

具体主题角色是随时都会发生变化的，只要它实现了接口，甭管它如何变化，都逃不脱如来佛的手掌（接口），那我们的代理类完全就可以在不做任何修改的情况下使用。

• <!--[if !supportLists]-->智能化

这在我们以上讲解中还没有体现出来，不过在我们以下的动态代理章节中你就会看到代理的智能化，读者有兴趣也可以看看Struts是如何把表单元素映射到对象上的。

12.3.2 代理模式的应用

我相信第一次接触到代理模式的读者肯定很郁闷，为什么要用代理呀，是的，为什么要用代理？想想现实世界吧，你为什么要找代理律师，你去打官司，为什么要找个律师？因为你不想参与中间过程的是是非非，只要完成自己的答辩就成，其他的比如事前调查、事后追查都由律师来搞定，这就是为了减轻你的负担。代理模式使用非常多，大家可以看看Spring AOP，这是一个非常典型的动态代理