AOP解决了面向对象和其它过程性语言未能处理的一块问题空间。
但我还是要问一问，如果使用AOP的话，能否避免其中一部分设计取舍呢？
即便是曾经祸害过每个开发者生活的Javascript，也有强大的方言能够方便地实现AOP。
这里定义的指标还会让读者更加容易地评估即将推出的AOP工具和特性。
因为它使用了面向对象编程，所以我们必须花费一些时间积累相关知识以更有效地使用AOP。
从AOP获得大部分好处的最佳实践之一就是使用元数据去为横向关注点（cross-cuttingconcerns）捕获连接点（joinpoints）。
在这个基础上做决定前要小心基准：SpringAOP代理的负载在通常使用中是无法觉察到的。
如果目的是分离关注点、透明性和灵活性，那么面向方面的编程（AOP）通常就是正确的答案。
我想谈论一些我认为AOP可以被（或已经被）有效使用的方法。
转移逻辑横贯所有拦截过滤器，你可能已经猜到了，AOP再次成为所选技术。
位于每个AOP工具核心的是连接点模型，它提供了一种机制，可以识别出在哪里发生了横切。
为了更加完整的回顾AOP方法，请您参考本文最后“引用”一节中所提供的资源。
同时使用AspectJ和SpringAOP是可能的：它们并不冲突。
使用AOP语言，我们可以自动测试应用程序代码而不会对代码带来干扰。
CedricBeust将面向方面编程（AOP）描述为“保留少数开发内行特权的一个绝佳主意”。
正如上面的图所展示的，AOP工具之间的关键差异就是处理方面声明的方式。
编写好的切入点是掌握好AOP的关键，尽管这对于新手来说通常不是一件容易的事。
当然给应用程序编码并不会像以前那样复杂，那时AOP与Spring尚并不存在。
阅读这篇文章和开始使用AspectsforMDD是不需要AOP相关知识的。
为项目选择一个AOP工具所面临的难题在于比较每种工具的优劣，同时不要让自己迷失其中。
在SpringAOP（所有版本）的案例中，唯一支持的连接点是公有方法的执行。
可以看出，提供注释的原理在不同的AOP系统中是相同的，尽管语法不一样。
在通过元数据增强的AOP实现中，就像平时做的那样，可以将核心关注点映射到类。
为了完成此次有关AOP的快速概述，我将介绍一些特定术语并解释它们各自的含义。
因此，需要将AOP程序作为一个单元来编译，而不能每次编译一个类。
AOP工具的方面声明的简洁性，应当有助于判断该工具静态检查的优势。
目前，虽然还存在其他研究质量的编译器，但是AspectJ编译器是惟一达到商业质量的AOP编译器。
AOP让故障处理的问题被封装在通用的可以作用到参与类的层面上。
在本文最后，我将说明使用AOP构造提供注释带来的一些设计可能性。