从装饰模式到aop

在上次的spring的源码中，我们在ioc中气势随处都可以见到拦截机制的实现，很多时候，针对于系统本身固有的拦截点，是采用策略模式留出了拦截的空方法实现，这个一个框架在设计的时候必然应该考虑的问题；然而针对一些系统无法预知的拦截，比如bean类的某方法的拦截，那么，我们只能采用动态代理的方式；

最初我们的拦截机制来自于大名鼎鼎的decorator模式，我们看如下代码：

1. package org.corey.demo;
3. public interface IPerson {
4.    public void say();
5. }

1. package org.corey.demo;
3. public class Person implements IPerson {
5.     public void say() {
6.         System.out.println("i am corey");
7.     }
9. }

1. package org.corey.demo;
3. public class DecoratorPerson implements IPerson {
4.     private IPerson concertPerson;
5. 
   
7.     public DecoratorPerson(IPerson concertPerson) {
           super();
           this.concertPerson = concertPerson;
       }
   
   
9.     public void say() {
10.         System.out.println("hello everyone");
11.         this.concertPerson.say();
12.     }
14. }

1. package org.corey.demo;
3. public class Demo {
5.     /**
6.      * @param args
7.      */
8.     public static void main(String[] args) {
9.         IPerson person=new Person();
10.         IPerson decorator=new DecoratorPerson(person);
11.         decorator.say();
12.         
13.     }
15. }

hello everyone
i am corey

可见在上述效果中，我们动态的增加了hello everyone;

但是，我们很快发现装饰模式一个不好的地方，比如现在Person有很多方法，而我们的Decorator只要改变其中的say，那么我们不得不把所有的方法重新实现一遍，其实这也是组合复用相对于继承复用的一个不足之处，组合复用事实上是采用委托的机制来实现，我们不得不把每一个功能都显示的进行委托，然而，继承复用有是一种编译器的复用，造成了代码的强耦合，比如现在IPerson的具体实现类有Student和Tearcher，那么我们如果我们要对两者都进行代理，我们不得不为两个类都派生出一个子类，然后作出装饰行为；
如：

1. Public class DecoratorStudent extends Student{
2.  public void say(){
3.   System.out.println("hello everyone");
4.   super.say();
5.  }
6. }

而Tearcher同理，而不是运行期间在DecoratorPerson的构造中传入不同类型的IPerson；


针对于这种缺点，我们不得不感Proxy给我们带来的惊喜；我们来看：

1. package org.corey.demo;
3. import java.lang.reflect.InvocationHandler;
4. import java.lang.reflect.Method;
5. import java.lang.reflect.Proxy;
7. public class CoreyInvocation implements InvocationHandler {
8.     Object delegation;
10.     public Object proxy(Object delegation) {
11.         this.delegation = delegation;
12.         return Proxy.newProxyInstance(delegation.getClass().getClassLoader(),
13.                 delegation.getClass().getInterfaces(), this);
14.     };
16.     public Object invoke(Object proxy, Method method, Object[] arg2)
17.             throws Throwable {
18.         System.out.println("hello everyone");
19.         return method.invoke(delegation, arg2);
20.     }
22. }

1. package org.corey.demo;
3. public class Demo {
5.     /**
6.      * @param args
7.      */
8.     public static void main(String[] args) {
9.         IPerson person=(IPerson)(new CoreyInvocation().proxy(new Person()));
10.         person.say();
11.         
12.     }
14. }

在Invocationhandler中，我们的invoke方法把这个不得不显示委托的缺点解决啦，我们可以在这里对方法进行统一的装饰，很快，我们又发现了不方便，如：
delegation.getClass().getInterfaces()
这说明一个问题，我们的代理类不得不实现一个接口，虽然面向接口编程是oo所呼吁的，但是却并不能说我们就一定时时刻刻的遵守，对于没有实现接口的代理类，那是不是我们没有办法进行动态代理啦呢？？？？

答案是no，我们必须再次感谢cglib给我们带来的这一切:

一下部分引子江南白衣blog：


 cglib的Enhancer说起来神奇，用起来一页纸不到就讲完了。
    它的原理就是用Enhancer生成一个原有类的子类，并且设置好callback到proxy， 则原有类的每个方法调用都会转为调用实现了MethodInterceptor接口的proxy的intercept() 函数：

public Object intercept(Object o,Method method,Object[] args,MethodProxy proxy)

 在intercept()函数里，你可以在执行Objectresult=proxy.invokeSuper(o,args);来执行原有函数，在执行前后加入自己的东西，改变它的参数值，也可以瞒天过海，完全干别的。说白了，就是AOP中的around advice。

    AOP没有出现以前，该领域经典的设计模式是Decorator，像Java IO Stream的设计就是如此.不过，如果为每个DAO, 每个方法的写Decorator函数会写死人的，所以用上cglib的好处是一次过拦截所有方法。 

     另外，cglib除了Enhancer之外，还有BulkBean和Transform，都是Hibernate持久化的基础，但文档贫乏，一时还没去看怎么用。

1.AOP里讲了一百遍阿一百遍的log aspect在cglib是这样做的:

   public class LogDAOProxy implements MethodInterceptor
   {
       private Logger log=Logger.getLogger(LogDAOProxy.class);
       private Enhancer enhancer=new Enhancer();
        //返回DAO的子类
       public Object getDAO(Class clz)
       {
           enhancer.setSuperclass(clz);
           enhancer.setCallback(this);
           return enhancer.create();
       }
       //默认的拦截方法
      public Object intercept(Object o,Method method,Object[] args,MethodProxy proxy) throws Throwable
      {
           log.info("调用日志方法"+method.getName());
           Object result=proxy.invokeSuper(o,args);
           return result;
      }
   }

    应用的代码:

    LogDAOProxy proxy = new LogDAOProxy();
    GoodsDAO  dao = (GoodsDAO)proxy.getDAO(GoodsDAO.class);
    dao.insert(goods);

2.而在Spring的管理下应该略加修改的高级Decorator
   上面的例子用return enhancer.create();创建子类实例，但在Spring管理下，一些Bean的实例必须由Spring来创建和管理，而不由enhancer来创建的。所以我对上述用法略加修改，使它真正当一个Proxy的角色，请对比黑体字的部分

  public class LogDAOProxy implements MethodInterceptor
  {
       private Logger log=Logger.getLogger(LogDAOProxy.class);
       private Object dao=null;
       private Enhancer enhancer=new Enhancer();
        //返回DAO的子类
       public Object getDAO(Class clz,Object dao)
       {
           this.dao = dao;
           enhancer.setSuperclass(clz);
           enhancer.setCallback(this);
           return enhancer.create();
       }      
       //默认的拦截方法
      public Object intercept(Object o,Method method,Object[] args,MethodProxy proxy) throws Throwable
      {
           log.info("调用日志方法"+method.getName());
           Object result=proxy.invoke(dao, args);
           return result;
      }
  }

可见，原来模式里在getDao()时由enhancer创建dao，而 调用intercept时则将enhancer创建的dao以Object o参数传回。
而新模式里，dao在getDao()时从外面传入，enhancer.create()返回的是一个proxy. 而调用intercept时，实际会用之前传入的dao进行操作，而忽略Object o参数传入的proxy.

有点遗憾, intercept函数里MethodProxy的Signature是固定的 , 即客户如果调用foo(String),你不可以用proxy.invoke偷换成foo(String,String);