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

时间:2023-02-14 08:53:29
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
Spring  AOP那些学术概念—通知、增强处理连接点(JoinPoint)切面(Aspect)

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

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

肉块 -  Advice

汉堡 -  AOP代理的方法。

将肉加到面包 - 引入

关键就是:切面定义了哪些连接点会得到通知。
 
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织入通知,并且把对这个子类的调用委托到目标类。
 
相比之下,还是兄弟模式好一些,她能更好的实现松耦合,尤其在今天都高喊着面向接口编程的情况下,父子模式只是在没有实现接口的时候,也能织入通知,应该当做一种例外。