做一个合格的程序猿之浅析Spring AOP源码（十六） 分析ProxyFactory

  其实说实话。通过上面2节的讲解，Spring AOP可以算分析完了，因为我们已经知道AOP最为核心的2个组件都不是ProxyFactoryBean，AspectJProxyFactory，亦或者是这节我们讲解的ProxyFactory，这三个基层的类，做的最重要的事都是去维护几个变量，有了这几个变量就可以做很多事，原因：

①变量adivsor中定义了advice，定义了通知，即定义了干什么

②定义了pointcut，且将与之对应的advice结合起来做出了advisor

③pointcut又是什么，恰恰这就是我们要目标对象

好了，一切都好了，也就说ProxyFactory只要按照自己的方式去维护好advisor，interface target就可以了

我们可以截取部分ProxyFactory的源码，其实它就是跟我们想的一样，去维护advisor，要代理的接口，要代理的目标对象

维护了advisor，interface

维护了目标对象

其他的方法大体与ProxyFactoryBean是一样的，例如获取代理对象

好了，其实没有什么好讲的，但是我还是单独开了一个节，因为我们要讲一下它出现的原因,因为proxyfactorybean的出现已经感觉很好的解决了很多问题，那么它出现的原因是什么呢？

第一点：proxyFactory很直接，对，很直接，简单粗暴，我需要什么，你就给我什么，我不想进行任何转化，判断，我们用的时候一般是这样的

对，他的出现感觉就很清爽，不需要分析，初级程序员（如我）一眼就能看懂它要干嘛，很少有spring源码中的类可以这么被我们直接使用

第二点：spring最擅长的是配置，一般来说我们只需要配置xml就ok了，像proxyfactory这种基于编程的类为什么会出现呢？

其实很简单，Spring的确不希望我们用proxyfactory来直接编程，违反了spring的设计原则，其实这个类是spring自己要用（spring怎么用下次分析），其实想想也是，其实spring也需要有proxyfactory这样的类，真的很朴素，拿来就用，这样给其在IoC部分去实例化的目标对象且返回代理对象提供了方便

第三点;这点也是我自己觉得proxyfactoryBean不好的地方，不知道大家有没有留意到，我们在上一节spring的配置文件中有这么一段：

然后我们是这么用的

如果大家没有看过proxyFactoryBean的源代码，我们用的时候就不觉得奇怪吗？明明bean的class是org.springframework.aop.framework.ProxyFactoryBean，但在运用的时候去转成了IBussinessService，这样不是很好理解，这样感觉还是有点怪的，也许这就是我们在实际开发环境中用proxyFactorybean去做AOP少的原因之一吧