动态代理类以及aop

动态代理类

　　Java动态代理类位于Java.lang.reflect包下，一般主要涉及到以下两个类：

　　(1). Interface InvocationHandler

　　(2).Proxy

public class Proxy
   
   
    
    extends 
    
    Object
   
   
   
   
    
    implements 
    
    Serializable
   
   

Proxy 提供用于创建动态代理类和实例的静态方法，它还是由这些方法创建的所有动态代理类的超类。

创建某一接口 Foo 的代理：

     InvocationHandler handler = new MyInvocationHandler(...);
     Class proxyClass = Proxy.getProxyClass(
         Foo.class.getClassLoader(), new Class[] { Foo.class });
     Foo f = (Foo) proxyClass.
         getConstructor(new Class[] { InvocationHandler.class }).
         newInstance(new Object[] { handler });
 

或使用以下更简单的方法：

     Foo f = (Foo) Proxy.newProxyInstance(Foo.class.getClassLoader(),
                                          new Class[] { Foo.class },
                                          handler);
 

动态代理类（以下简称为代理类）是一个实现在创建类时在运行时指定的接口列表的类，该类具有下面描述的行为。 代理接口 是代理类实现的一个接口。 代理实例 是代理类的一个实例。 每个代理实例都有一个关联的调用处理程序 对象，它可以实现接口 InvocationHandler。通过其中一个代理接口的代理实例上的方法调用将被指派到实例的调用处理程序的 Invoke 方法，并传递代理实例、识别调用方法的 java.lang.reflect.Method 对象以及包含参数的 Object 类型的数组。调用处理程序以适当的方式处理编码的方法调用，并且它返回的结果将作为代理实例上方法调用的结果返回。

代理类具用以下属性：

• 代理类是公共的、最终的，而不是抽象的。
• 未指定代理类的非限定名称。但是，以字符串 "$Proxy" 开头的类名空间应该为代理类保留。
• 代理类扩展 java.lang.reflect.Proxy。
• 代理类会按同一顺序准确地实现其创建时指定的接口。
• 如果代理类实现了非公共接口，那么它将在与该接口相同的包中定义。否则，代理类的包也是未指定的。注意，包密封将不阻止代理类在运行时在特定包中的成功定义，也不会阻止相同类加载器和带有特定签名的包所定义的类。
• 由于代理类将实现所有在其创建时指定的接口，所以对其 Class 对象调用 getInterfaces 将返回一个包含相同接口列表的数组（按其创建时指定的顺序），对其 Class 对象调用 getMethods 将返回一个包括这些接口中所有方法的 Method 对象的数组，并且调用 getMethod 将会在代理接口中找到期望的一些方法。
• 如果 Proxy.isProxyClass 方法传递代理类（由 Proxy.getProxyClass 返回的类，或由 Proxy.newProxyInstance 返回的对象的类），则该方法返回 true，否则返回 false。
• 代理类的 java.security.ProtectionDomain 与由引导类加载器（如 java.lang.Object）加载的系统类相同，原因是代理类的代码由受信任的系统代码生成。此保护域通常被授予 java.security.AllPermission。
• 每个代理类都有一个可以带一个参数（接口 InvocationHandler 的实现）的公共构造方法，用于设置代理实例的调用处理程序。并非必须使用反射 API 才能访问公共构造方法，通过调用 Proxy.newInstance 方法（将调用 Proxy.getProxyClass 的操作和调用带有调用处理程序的构造方法结合在一起）也可以创建代理实例。

代理实例具有以下属性：

• 提供代理实例 proxy 和一个由其代理类 Foo 实现的接口，以下表达式将返回 true：

       proxy instanceof Foo
   

  并且以下的强制转换操作将会成功（而不抛出 ClassCastException）：

       (Foo) proxy
   

• 每个代理实例都有一个关联的调用处理程序，它会被传递到其构造方法中。静态 Proxy.getInvocationHandler 方法将返回与作为其参数传递的代理实例相关的调用处理程序。
• 代理实例上的接口方法调用将按照该方法的文档描述进行编码，并被指派到调用处理程序的 Invoke 方法。
• 在代理实例上的 java.lang.Object 中声明的 hashCode、equals 或 toString 方法的调用将按照与编码和指派接口方法调用相同的方式进行编码，并被指派到调用处理程序的 invoke 方法，如上所述。传递到 invoke 的 Method 对象的声明类是 java.lang.Object。代理类不重写从 java.lang.Object 继承的代理实例的其他公共方法，所以这些方法的调用行为与其对 java.lang.Object 实例的操作一样。

在多代理接口中重复的方法

当代理类的两个或多个接口包含一个具有相同名称和参数签名的方法时，代理类的接口顺序变得非常重要。在代理实例上调用重复方法 时，传递到调用处理程序的 Method 对象没有必要成为其声明类可以从接口（通过该接口调用代理方法）的引用类型指派的对象。此限制存在的原因是，生成的代理类中的相应方法实现无法确定它通过哪一个接口调用。因此，在代理实例上调用重复方法时，第一个接口中的方法的 Method 对象包含接口的代理类列表中的方法（直接或通过超级接口继承），该对象会传递到调用处理程序的 invoke 方法，无论该方法调用通过哪一种引用类型发生。

如果代理接口包含某一方法，它的名称和参数签名与 java.lang.Object 的 hashCode、equals 或 toString 方法相同，那么在代理实例上调用这样的方法时，传递到调用处理程序的 Method 对象将使 java.lang.Object 成为其声明类。换句话说，java.lang.Object 公共的非最终方法理论上在所有代理接口之前，以便确定哪一个 Method 对象传递到调用处理程序。

还要注意，当重复方法被指派到调用处理程序时，invoke 方法只可以抛出经过检查的异常类型，该异常类型可以使用所有 代理接口（可以通过它调用）中方法的 throws 子句指派一种异常类型。如果 invoke 方法抛出一个经过检查的异常，该异常没有指派给任何由一个代理接口（可以通过它调用）中的方法声明的异常类型，那么该代理实例上的调用将抛出一个未经检查的 UndeclaredThrowableException。此限制表示并非所有的由传递到 invoke 方法的 Method 对象上调用 getExceptionTypes 返回的异常类型都可以由 invoke 方法成功抛出

public interface InvocationHandler

InvocationHandler 是代理实例的调用处理程序 实现的接口。

每个代码实例都具有一个关联的调用处理程序。对代理实例调用方法时，将对方法调用进行编码并将其指派到它的调用处理程序的 invoke 方法。

 

invoke

Object invoke(Object proxy,
              Method method,
              Object[] args)
              throws Throwable

在代理实例上处理方法调用并返回结果。在与方法关联的代理实例上调用方法时，将在调用处理程序上调用此方法。

 

参数：

proxy - 在其上调用方法的代理实例

method - 对应于在代理实例上调用的接口方法的 Method 实例。 Method 对象的声明类将是在其中声明方法的接口，该接口可以是代理类赖以继承方法的代理接口的超接口。

args - 包含传入代理实例上方法调用的参数值的对象数组，如果接口方法不使用参数，则为 null。基本类型的参数被包装在适当基本包装器类（如 java.lang.Integer 或 java.lang.Boolean）的实例中。

返回：

从代理实例的方法调用返回的值。如果接口方法的声明返回类型是基本类型，则此方法返回的值一定是相应基本包装对象类的实例；否则，它一定是可分配到声明返回类型的类型。如果此方法返回的值为 null 并且接口方法的返回类型是基本类型，则代理实例上的方法调用将抛出 NullPointerException。否则，如果此方法返回的值与上述接口方法的声明返回类型不兼容，则代理实例上的方法调用将抛出 ClassCastException。

抛出：

Throwable - 从代理实例上的方法调用抛出的异常。该异常的类型必须可以分配到在接口方法的 throws 子句中声明的任一异常类型或未经检查的异常类型 java.lang.RuntimeException 或 java.lang.Error。如果此方法抛出经过检查的异常，该异常不可分配到在接口方法的 throws 子句中声明的任一异常类型，代理实例的方法调用将抛出包含此方法曾抛出的异常的 UndeclaredThrowableException。

代理的意思很好理解，它借鉴了我们日常所用的代理的意思：就是本来该自己亲自去做的某件事，由于某种原因不能直接做，而只能请人代替你做，这个被你请来做事的人就是代理。比如过春节要回家，由于你要上班，没时间去买票，就得票务中介代你购买，这就是一种代理模式。这个情景可以形象的描述如下：

class：火车站

{

        卖票：

       {……}

}

    火车站是卖票的地方，我们假设只能在火车站买到票。卖票的动作实质是火车站类完成的。

Class：票务中介

{

        卖票：

        {

               收中介费；

              火车站.卖票；

}

}

    顾客找票务中介买票的时候，调用票务中介.卖票。票务中介其实做了两件事，一是去火车站买票，二是不能白帮你卖票，肯定要收中介费。而你得到的好处是不用直接去火车站买票，节省了买票的时间用来上班。

    以上我们简单模拟了代理模式的情景和为什么要使用代理模式，下面我们以一个例子来具体分析一下JAVA中的代理模式。

    假设有一个信息管理系统，用些用户有浏览信息的权限，有些用户有浏览、添加和修改信息的权限，还有些用户有除了上述的权限，还有删除信息的权限，那么我们最容易想到的做法如下：

public class ViewAction

{

        //由userId计算权限

        ……

        String permission = ……;

       if(permission.equals(Constants.VIEW))

        {

               System.out.println(“You could view the information……”);

               ……

}

}

    其他的动作都和浏览信息的动作差不多。我们来看这样的类，很容易看出它的一些缺点来：第一、它把权限计算和动作执行都放在一个类里，两者的功能相互混在一起，容易造成思路的混乱，而且修改维护和测试都不好；一句话来说，它不满足单一职责原则。第二是客户调用的时候依赖具体的类，造成扩展和运行期内的调用的困难，不满足依赖颠倒原则。

    既然有这么多的问题，我们有必要对该类进行重新设计。其实大家早已想到，这个类应该使用代理模式。是啊，和我们买火车票的动作一样，动作类不能直接执行那个动作，而是要先检查权限，然后才能执行；先检查权限，后执行的那各类其实就是一个代理类，修改后的代码如下：

public interface Action

{

        public void doAction();

}

   首先是设计一个接口，用来满足依赖颠倒原则。

Public class ViewAction implements Action

{

        public void doAction()

        {

               //做View的动作

               System.out.println(“You could view the information……”);

               ……

}

}

    这个类跟火车站一样，是动作的真实执行者。

Public class ProxyViewAction implements Action

{

        private Action action = new ViewAction();

        public void doAction()

        {

               //调用权限类的方法取得用户权限

               if(Permission.getPermission(userId).equals(Constants.VIEW))

               {

                      action.doAction();

}

}

}

    这是代理类，很容易理解。在我们的ProxyViewAction类中，除了做了客户真正想要做的动作：doAction()以外，还进行了额外的动作检查用户的权限。而作核心动作doAction()是在一个干干净净的类：ViewAction中进行，这个类只做核心动作，对其他的不关心，满足了单一职责原则。

    客户端通过调用代理类来执行动作，而代理类一是将权限判断和动作的执行分离开来，满足了单一职责原则；二是实现了一个接口，从而满足了依赖颠倒原则。比第一个思路好了很多。

    代理又被称为委派，说的是代理类并不真正的执行那个核心动作，而是委派给另外一个类去执行，如ProxyView类中，ProxyView类并没有真正执行doAction()方法，而是交给ViewAction类去执行。

    我们再来看代理类ProxyViewAction，可以看到它不仅依赖于接口Action，而且依赖于具体的实现ViewAction。这样对我们的系统扩展很不利，比如我们有Add动作、Delete动作、Modify动作等等，我们需要对每一个动作都写一个代理类，而这些代理类都做同样的事情，先进行权限判断，然后再委派。所以我们需要对这些代理再进行一次抽象，让它只依赖接口Action，而不依赖于具体的实现。

    要实现这样的想法，我们需要将代理类中的具体实现提走，让代理的使用者在运行期提供具体的实现类，即所谓的依赖注入，如下：

Public class ProxyAction implements Action

{

        private Action action;

        public ProxyAction(Action action)

        {

               this.action = action;

}

        public void doAction()

        {

               //调用权限类的方法取得用户权限

               if(Permission.getPermission(userId).equals(action.getClass().getName()))

               {

                      action.doAction();

}

}

}

    这样，我们就将所有实现了Action接口的实现使用一个代理类来代理它们。除了ViewAction类能用，以后扩展的AddAction、       ModifyAction、DeleteAction类等等，都可以使用一个代理类：ProxyAction。

    而我们的客户端类似如下：

Action action = ProxyAction(new ViewAction);

Action.doAction();

    通过对代理类的依赖注入，我们使得代理类初步有了一定扩展性。但是我们还要看到，这个代理类依赖于某一个确定的接口。这仍然不能满足我们的实际要求，如我们的系统的权限控制一般是整个系统级的，这样系统级的权限控制，我们很难在整个系统里抽象出一个统一的接口，可能会有多个接口，按照上面的代理模式，我们需要对每一个接口写一个代理类，同样，这些类的功能都是一样的。这显然不是一个好地解决办法。

    基于上面的原因，我们需要解决一个系统在没有统一的接口的情况下，对一些零散的对象的某一些动作使用代理模式的问题。JAVA API为我们引入了动态代理或动态委派的技术。

    动态代理的核心是InvocationHandler接口，要使用动态代理就必须实现该接口。这个接口的委派任务是在invoke(Object proxy, Method m, Object[] args)方法里面实现的：

//在调用核心功能之前作一些动作

……

//调用核心功能

m.invoke(obj, args);

//在调用核心功能以后做一些动作

……

    我们可以看到动态代理其实用的是反射机制来调用核心功能的：m.invoke(obj, args);正是这种反射机制的使用使得我们调用核心功能更加灵活，而不用依赖于某一个具体的接口，而是依赖于Object对象。

    下面我们来具体看看动态代理或动态委派如何使用：

public class ProxyAction implements InvocationHandler {

private Object action;

public ProxyAction(Object action)

{

       this.action = action;

}

public static Object getInstance(Object action)

{

        return Proxy.newProxyInstance(action.getClass().getClassLoader(),

action.getClass().getInterfaces(),new ProxyAction(action));

}

 

public Object invoke(Object proxy, Method m, Object[] args)

               throws Throwable {

       

        Object result;

 

       try {

                      //在委派之前作动作，如权限判断等

           System.out.println("before method " + m.getName());

                      //进行委派

           result = m.invoke(action, args);

 

       } catch (InvocationTargetException e) {

 

           throw e.getTargetException();

 

       } catch (Exception e) {

 

           throw new RuntimeException("unexpected invocation exception: "

 

                  + e.getMessage());

 

       } finally {

                      //在委派之后做动作

           System.out.println("after method " + m.getName());

 

       }

 

       return result;

 

　

}

 

}

 

    这个代理类，首先是实现了InvocationHandler接口；然后在getInstance（）方法里得到了代理类的实例；在invoke（）方法里实现代理功能，也很简单。

    下面我们来看客户端：

Action action = (Action)ProxyAction.getInstance(new ViewAction());

Action.doAction();

    我们可以看到代理类对接口的依赖也转移到了客户端上，这样，代理类不依赖于某个接口。对于同样的代理类ProxyAction，我们也可以有如下的客户端调用：

Engine engine = (Engine)ProxyAction.getInstance(new EngineImpl());

Engine.execute();

    只要engineImpl类实现了Engine接口，就可以像上面那样使用。

    现在我们可以看到，动态代理的确是拥有相当的灵活性。但我们同时也看到了，这个代理类写起来比较麻烦，而且也差不多每次都写这样千篇一律的东西，只有委派前的动作和委派后的动作在不同的代理里有着不同，其他的东西都需要照写。如果这样的代理类写多了，也会有一些冗余代理。需要我们进一步优化，这里我们使用模板方法模式来对这个代理类进行优化，如下：

public abstract class BaseProxy implements InvocationHandler {

private Object obj;

protected BaseProxy(Object obj)

{

       this.obj = obj;

}

public static Object getInstance(Object obj,InvocationHandler instance)

{

        return Proxy.newProxyInstance(obj.getClass().getClassLoader(),

obj.getClass().getInterfaces(),instance);

}

 

public Object invoke(Object proxy, Method m, Object[] args)

               throws Throwable {

        // TODO Auto-generated method stub

        Object result;

 

       try {

 

           System.out.println("before method " + m.getName());

           this.doBegin();

 

           result = m.invoke(obj, args);

 

       } catch (InvocationTargetException e) {

 

           throw e.getTargetException();

 

       } catch (Exception e) {

 

           throw new RuntimeException("unexpected invocation exception: "

 

                  + e.getMessage());

 

       } finally {

 

           System.out.println("after method " + m.getName());

           this.doAfter();

 

       }

 

       return result;

 

　

}

public abstract void doBegin();

public abstract void doAfter();

 

}

    这样，代理的实现类只需要关注实现委派前的动作和委派后的动作就行，如下：

public class ProxyImpl extends BaseProxy {

protected ProxyImpl(Object o)

{

       super(o);

}

public static Object getInstance(Object foo)

{

        return getInstance(foo,new ProxyImpl(foo));

}

 

//委派前的动作

public void doBegin() {

        // TODO Auto-generated method stub

       System.out.println("begin doing....haha");

 

}

 

//委派后的动作

public void doAfter() {

        // TODO Auto-generated method stub

       System.out.println("after doing.....yeah");

 

}

 

}

    从上面的代码，我们可以看出代理实现类的确是简单多了，只关注了委派前和委派后的动作，这是我们作为一个代理真正需要关心的。

    至此，代理模式和动态代理已经告一段落。我们将动态代理引申一点说开去，来作为这篇文章的蛇足。

    这个话题就是面向方面的编程，或者说AOP。我们看上面的ProxyImpl类，它的两个方法doBegin()和doAfter()，这是做核心动作之前和之后的两个截取段。正是这两个截取段，却是我们AOP的基础。在OOP里，doBegin()，核心动作，doAfter()这三个动作在多个类里始终在一起，但他们所要完成的逻辑却是不同的，如doBegin()可能做的是权限，在所有的类里它都做权限；而在每个类里核心动作却各不相同；doAfter()可能做的是日志，在所有的类里它都做日志。正是因为在所有的类里，doBegin()或doAfter()都做的是同样的逻辑，因此我们需要将它们提取出来，单独分析、设计和编码，这就是我们的AOP的思想。

    这样说来，我们的动态代理就能作为实现AOP的基础了。好了，就说这么多，关于AOP技术，我们可以去关注关于这方面的知识。

来源：

1.java.doc.sdk_1.5.0

2.http://blog.163.com/shn_000/blog/static/17131391200841634142946/