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?