用家常话，聊聊一些费解的AOP概念

前一篇文章呢对 JDK 的动态代理说了一番，也花了不少时间来写那边文章。有时候觉得心里的想法要靠笔杆子（键盘）来表达出来，至少说精确表达还是有一定难得的。也许这就是草根阶层的笔民与作家之间的差距吧。 OK ， Whatever 感慨少发。切入正题 :AOP.

  有时候我怀疑自己到底是个完美主义者还是个做事慢性子的人，总觉得做什么之前得想好了。先做什么在做什么。比如讲 AOP 吧，估计两篇文章下来都没正经的说给大家写了个 Spring 框架下的小例子，搞几行代码怎么的。可回头想想，代码 - 网上一大堆 ; 例子 — 参考书写的比我周全。我还不如讲点 WHY 少点 HOW 就跟打球一样基本功好了，什么动作都好做。基本功不行，运球过半场都成问题。

  先从 AOP 的概念说起吧，我们不再去看 Spring-framework 的参考手册。那些太专业，人家限于篇幅都是以最精辟最简短的词语来写，目的达到了，可问题来了真正有几个人能把 Cross cutting concern Aspect 等等概念说的大众化，普通话。让没接触过 Spring 不知道 Spring 为何物的 JAVA 初学者们一目了然呢？

    我们平常所接触的 OOP 都是一个纵向的编程理念，从上往下先做什么后做什么。比如你上网购物，你得先登录然后你在购买，这是一个流程。假如登录时需要安全性检查、事务、记录日志等，（其实这些都不属于我们的业务逻辑）。所以我们就不该把这些不属于业务逻辑的代码散布在业务逻辑类之中。此时我们添加一个横向的编程。等业务逻辑到这一步我们就通过横向方法实现（也是面向切面的实现）。你所需要实现的横向功能（或者说需求吧）就是所谓的 cross cutting concern （横切关注点这个概念比较抽象，谁给大家细说说参考手册中对这个也是很模糊一带而过）。

   而 Aspect 就是将 cross cutting concern 模块化，抽取出来形成的一个具体的类。之前你肯能需要在每一个需要进行安全性检查的类中都去自己实现检查，而现在不同。 AOP 将它模块化，所有的安全性检查都交给 Aspect 来做，你的类中就只管实现自己所需要的业务逻辑了从而你的代码清晰，功能明确！有人可能要问了，那我自己写的类怎么调用这些安全性检查呢？答案是： Spring 会帮你实现（不然还那么麻烦用什么框架呢）。想起代理了吗？（我在前一篇文章《从 JDK 动态代理说 Spring 的 AOP 》说的比较详细，可以去看看）。

  需要的功能我们抽取出来了 ( 就是说得到切面 Aspect 了 ) ，之后就得去设计具体的方法了（比如需要验证，那我们就写一个验证方法呗）。此时 Advice 就应运而生了，我们在具体的 Aspect 类中去设计具体的方法（也是设计 Advice ，现在应该明白 Advice 的大概了吧其实它就是一个方法。只是 Spring 给它取名曰：通知）。比如我要写一个用验证的安全类 Security （负责所有的验证功能） , 当中有个方法叫 checkSecurity(), 在调用其他方法之前调用它那它就成了前置通知（ before 的概念有了吗？），之后调用就是后置通知（ after ）异常时调用就成（ Throws 通知）。等等 ..

  通知设计完之后我们需要调用啊，可是不是所有的方法都需要这一方法（如果不管三七二十一所有方法通过这横切面就需要调用，那效率何在？这不比收费站，你过就得给钱啊。呵呵 有车的朋友应该感受比较深刻），这时就需要进行判断了。判断的依据就是 Pointcut ，比如我只需要对方法名称开头为 add 的方法调用，那此时的 Pointcut 或许就定义为 add* 了。这下该明白什么是 PC 了吧，他就是一套表达式，常用的就支持正则表达式 通过他来进行方法的筛选，类似过滤器。

  通知我们设计好了，也进行了筛选了现在就是将刷选的通添加到我的 Target Object 了（这一步 Spring 是通过代理实现的）。这个添加的过程就是所谓的 Weave ， Spring 给了个很酷的名字“织入”。而 TO （目标对象）就是需要调用通知的那个类（暂且说类吧，形象点），而 TO 中那个可以触发通知的方法就是所谓的 JoinPoint 。

   为了形象话，我把这一些概念组合起来画了个简单的示意图对照那个看文章会更加容易理解的。（JAVAEYE好像不让传本地图片上来，我就在附件里吧。就是麻烦点了）

  说了这么多，其实要真正理解 AOP 还是那两个关键字眼：代理（ Proxy ） . 这个明白了，那就是你熟练与否的问题了。而熟练就是你花时间多少的问题了。