Spring AOP Aspect Adivisor区别

AOP那些学术概念—通知、增强处理连接点（JoinPoint)切面（Aspect）

1、我所知道的AOP

初看起来，上来就是一大堆的术语，而且还有个拉风的名字，面向切面编程，都说是OOP的一种有益补充等等。一下让你不知所措，心想着：管不得很多人都和我说AOP多难多难。当我看进去以后，我才行发现：他就是一些Java基础上的朴实无华的应用，包括IOC（见 《Spring IOC(依赖注入、控制反转)概念理解》），包括许许多多这样的名词，都是万变不离其宗而已。

2、为什么要用AOP

1）就是为了方便，看一个国外很有名的大师说，编程的人都是“懒人”，因为他把自己做的事情都让程序去做了。用了AOP能让你少写很多代码，这点就够充分了吧。

2）就是为了更清晰的逻辑，可以让你的业务逻辑去关注自己本身的业务，而不去想一些其他的事情。这些其他的事情包括：安全，事物，日志等等。

3、那些AOP术语

初看这么多术语，一下子都不好接受，慢慢来，很快就会搞懂。

1. 通知、增强处理（Advice） 就是你想要的功能，也就是上说的安全、事物、日子等。你给先定义好，然后再想用的地方用一下。包含Aspect的一段处理代码
2. 连接点（JoinPoint） 这个就更好解释了，就是spring允许你是通知（Advice）的地方，那可就真多了，基本每个方法的钱、后（两者都有也行），或抛出异常是时都可以是连接点，spring只支持方法连接点。其他如AspectJ还可以让你在构造器或属性注入时都行，不过那不是咱们关注的，只要记住，和方法有关的前前后后都是连接点。
3. 切入点（Pointcut） 上面说的连接点的基础上，来定义切入点，你的一个类里，有15个方法，那就有十几个连接点了对吧，但是你并不想在所有方法附件都使用通知（使用叫织入，下面再说），你只是想让其中几个，在调用这几个方法之前、之后或者抛出异常时干点什么，那么就用切入点来定义这几个方法，让切点来筛选连接点，选中那几个你想要的方法。
4. 切面（Aspect） 切面是通知和切入点的结合。现在发现了吧，没连接点什么事，链接点就是为了让你好理解切点搞出来的，明白这个概念就行了。通知说明了干什么和什么时候干（什么时候通过方法名中的befor，after，around等就能知道），二切入点说明了在哪干（指定到底是哪个方法），这就是一个完整的切面定义。
5. 引入（introduction） 允许我们向现有的类添加新方法属性。这不就是把切面（也就是新方法属性：通知定义的）用到目标类中吗
6. 目标（target） 引入中所提到的目标类，也就是要被通知的对象，也就是真正的业务逻辑，他可以在毫不知情的情况下，被咋们织入切面。二自己专注于业务本身的逻辑。
7. 代理（proxy） 怎么实现整套AOP机制的，都是通过代理，这个一会儿给细说。
8. 织入（weaving） 把切面应用到目标对象来创建新的代理对象的过程。有三种方式，spring采用的是运行时，为什么是运行时，在上一文《Spring AOP开发漫谈之初探AOP及AspectJ的用法》中第二个标提到。
9. 目标对象 – 项目原始的Java组件。
10. AOP代理  – 由AOP框架生成java对象。
11. AOP代理方法 = advice +　目标对象的方法。

下面的图简化和形象的说明了AOP

形象上看，AOP编程，就像做汉堡一样。

原始面包 - 目标对象的方法。业务组件就行了。

肉块 -  Advice

汉堡 -  AOP代理的方法。

将肉加到面包 - 引入

总结：

根据转载的别人文章结合自己的理解 以下3点！！

1、Adivisor是一种特殊的Aspect，Advisor代表spring中的Aspect 

2、区别：advisor只持有一个Pointcut和一个advice，而aspect可以多个pointcut和多个advice

3：关键就是：切面定义了哪些连接点会得到通知，意思就是一个切面由切入点和通知组成（在切入点里执行通知：而通知前后方法（调用的切面类中的方法！））

4、我所理解的AOP原理

spring用代理类包裹切面，吧他们织入到Spring管理的bean中，也就是说代理类伪装成目标类，它会截取对目标类中方法的调用，然调用者对目标类的调用都先变成伪装类，伪装类这就先执行了切面，再把调用转发给真正的目标bean。

现在可以自己想一想，怎么搞出来这个伪装类，才不会被调用者发现（过JVM的检查，JAVA是强类型检查，哪里都要检查类型）。

1）实现和目标类相同的接口。

我也实现和你一样的接口，反正上层都是接口级别的调用，这样我就伪装成了和目标类一样的类（实现了同意接口，咱是兄弟了），也就逃过了类型检查，到java运行期的时候，利用多态的后期绑定（所以spring采用运行时），伪装类（代理类）就变成了接口的真正实现，二他里面包裹了真实的那个目标类，最后实现具体功能的还是目标类，只是不过伪装在之前干了点事情（写日志，安全检查，事物等）。

这就好比一个人让你办事，每次这个时候，你弟弟就会出来，当然他分不出来了，以为是你，你这个弟弟虽然办不了这个事，但是她知道你能办，所以就答应下来了，并且收了点礼物（写日志），收完礼物了，给把事给人家办了啊，所以你弟弟又找你这个哥哥来了，最后把这事办了还是你自己。但是你自己并不知道你弟弟已经收了礼物了，你只是专心把这件事做好。

顺着这个思想，要是本身这个类就没实现一个接口呢，你怎么伪装我，我就压给没有机会让你搞出这个双胞胎弟弟，那么就用第2种代理方式，创建一个目标类的子类，生个儿子，让儿子伪装我。

2）生成子类调用。

这次用子类来做伪装，当然这样也能逃过JVM的强类型检查，我继承的吗，当然查不出来了，子类重写了目标类的所有方法，当然在这些重写的方法中，不仅实现了目标类的功能，还在这些功能之前，实现了一些其他的（写日志，安全检查，事物等）。

这次的对比就是，儿子先从爸爸那儿把本事都学会了，所有人都找儿子办事，但是儿子每次办和爸爸同样的事之前，都要收点小礼物（写日志），然后才去办真正的事。当然爸爸是不知道儿子这么干的了。这里就有事情要说，某些本事是爸爸独有（final的），儿子学不会，学不了就办不了这个事，办不了这个事情，自然就不能收人家的礼物了。

前一种兄弟模式，spring会使用JDK的java.lang.reflect.Proxy类，它允许Spring动态生成一个新类来实现必要的接口，织入通知，并且把这些接口的任何调用都转发到目标类。

后一种父子模式，spring使用CGLIB库生成目标类的一个子类，在创建这个子类的时候，spring织入通知，并且把对这个子类的调用委托到目标类。

相比之下，还是兄弟模式好一些，她能更好的实现松耦合，尤其在今天都高喊着面向接口编程的情况下，父子模式只是在没有实现接口的时候，也能织入通知，应该当做一种例外。