Aspects：一个处理注解的简单工具？

尽管很多人认为Aspect适用于像事务管理、缓存、持久化、基于角色的安全等方面的横向关注点（cross-cutting concerns），Ramnivas Laddad提到了其另外一种重要价值，就是作为普通项目应用注解的推动者。

注解，在Java SE 5.0中作为Java元数据工具（JSR 175）被加入，提供了一种给程序元素增加元数据的方法。它们被用来配置容器、描述持久层配置、设置安全角色，并且由几乎全部最新的JSR标准所定义。它们还包含了给Java代码增加自定义注解的机制，以及通过反射提供编程访问元数据注解的方法。

面向方面编程（AOP）已经被用来实现各种横向关注点（cross-cutting concerns），范围从简单的日志到高级的应用程序安全和事务管理。使用Aspects作为一种实现注解处理器的方法，则是对它们的一种不同思考方法，不同于传统架构师的“横向关注点（cross cutting concerns）”视角的方法。Ramnivas谈到了利用Aspect和AOP注解，通过使用自定义注解给Java应用程序增加横向行为（cross-cutting behavior）。他谈论了元数据和AOP相互给对方带来了什么。元数据给选择连接点（join points）带来了附加信息，在那里Pointcuts使用注解来捕获连接点（join points）。在特定用例情况下，它还帮助创建松耦合的aspect。而AOP则带来了一种消费和供应注解的系统的方法。使用AOP供应元数据还给我们带来了整洁代码。使用AOP消费元数据比起使用注解处理工具（APT）选项来有不少好处。

Ramnivas告诫说使用元数据扩展Java语言可能是双刃剑（既强大又危险）。另一方面，注解使我们无需修改核心语言就可以给Java语言增加新的特性，这就使其成为了一个开放的语言；在最好情况下，原则性的扩展能够克服宿主语言的局限性。另一方面，不标准的、特别的、不连贯注解集可能导致代码不容易被理解。

从AOP获得大部分好处的最佳实践之一就是使用元数据去为横向关注点（cross-cutting concerns）捕获连接点（join points）。记住，注解应该在连接点处描述什么是“true”（条件）——在这些points处什么不应该发生（动作）。他还建议开发者使用已有的注解（比如@Entity、@Table、@WebService等）。把没有元数据的pointcut看作是首选并依赖于编程元素本身。而且，要避免特定实现的注解。了解一起使用元数据和AOP的代价和好处是有帮助的。元数据可以以各种方式被消费，了解这些使用方式将帮助我们洞悉AOP和元数据的结合。Ramnivas在其AOP和元数据的文章（第1部分和第2部分）中给出了一些最佳实践并且建议开发者不要过分追求自定义注解。

在实现自定义注解过程中主要的设计考虑是，什么（元数据，行为）、何时（编译时，运行时）、如何（APT，运行时反射，AOP）在Java应用程序中应用注解。John Heintz最近做了一个关于给Java注解增加行为的片子，里面他比较了在Java应用中实现自定义注解的不同设计技术。John讨论了字节码转换，其包括Aspect，将其作为三种类型注解处理选项之一。

• 产生器：这一注解处理选项包括读取源码并产生新的源码或修改已有源码。ATP和XDoclet属于这一类型。
• 字节码转换：这些注解处理器解析带有注解的类文件并释放出修改过的类和新产生的类。它们还可能产生非类产物如XML配置文件。字节码转换的例子包括AspectJ、Spring、Hibernate、CGLib和BCEL。
• 运行时反射：这个选项使用反射API在运行时用程序检查对象。运行时反射的例子有如Java 5+ 反射和Commons Attributes类库。测试框架JUnit和TestNG使用运行时反射处理注解。

InfoQ就实现自定义注解过程中Aspect所扮演的角色采访了John。他说实际上它只是在实现自定义注解时应该被考虑的一种平衡力量（工程上的折中）。他还提到注解基于方面的实现提供了实现注解行为的大多数简便方法和一个集中的定义。但是开发者必须清楚地记录非本地语义和对于构建或部署工具链（tool-chain）（编译或运行时编织）的影响。

查看英文原文：Aspects: An Easy Tool for Annotation Handling?