将常见可重用的行为以定制注解的方式添加到 Java 应用中是一种非常棒的方式，但如果开发者在决定使用注解的时候能够遵循一些开发标准和最佳实践的话，那就更事半功倍了。比如说在计划使用注释之前，比较一下当前情况下是不是注释真的比内迁代码和接口更为贴切。New Aspects 的 John Heintz 在最近举行的 No Fluff Just Stuff（ NFJS ）俄亥俄州软件中心研讨会（ COSS ）上作了一个演讲，讨论了向Java 注解添加行为的多种设计技术。
讲中，John 简要地谈到了字节码和元编程技术，大体介绍了Java 应用中的元数据是如何在早期Java 版本中使用属性文件、XML 到现在逐渐发展到注解上来的过程。他也提到了制定 JSR-175 规范的目的在于为 Java 语言提供元数据工具，比如 Java 5 中就已经添加了注解。
定义注解与定义接口的方式相似（使用 @Interface 类型来声明注解）。注解不仅可以用在包级别上，也可以用在类成员（属性、方法、构造方法），甚至还可以用在方法的局部参数上。
保持策略（retention policy）是实现注解的重要一环，根据数据在内存中保持时间的长短，有三种类型的保持策略：
- Runtime（一直保留数据，可以通过反射来访问）
- Class（数据保留在字节码中，无法在运行时访问）
- Source（编译器不保留该数据）
一些流行框架如 EJB3 、 Hibernate 、 Spring 、 Seam 、 Struts 2 、 RIFE 及 JAX-WS 的新版本都开始支持注解。John 论述了处理注解的三种方式：
生成器：
这种注解处理方式是通过读取源代码来产生新的源代码，或修改现存源代码及其它一些文件（XML、文档等等）来实现。生成器主要依赖于容器或其它编码约定，可以在任何保持策略下工作。
使用生成器的例子有注解处理工具（Annotation Processing Tool，即 APT ）和处理器、 XDoclet 、Spoon（针对 Java 的扩展编译器）、 APT-Jelly （一个模板库）等。APT 不允许你修改源代码，但对产生辅助文件却有相当大的帮助（像 WSDL、文档）。
字节码转换：
注解处理器对带有注解的类文件进行解析，然后对类做一些设当的修改。此外，他们也能生成其他类型的文件（比如 XML 配置文件）。字节码转换器在离线状态（编译期）、在装载期都能运行，还能在运行时动态运行（使用 JVMTI API）。在 class 或 runtime 这样的保持策略下，它都能运行。
使用字节码转换器的例子有 AspectJ 、Spring、Hibernate、 CGLib 、 Javassist 、 ASM 、 BCEL 等。
运行时反射：
这种方式使用反射 API 以编程的方式在运行阶段检查对象。它主要依赖于容器或其他编码约定，同时也需要 runtime 保持策略。
使用运行时反射的例子有：Java 5 及更新 Java 版本中的反射、 Commons Attributes 。 像 JUnit 和 TestNG 这样的测试框架也使用运行时反射来处理注解。
John 采用一个 Java 示范应用向大家展示了如何结合 APT、Javassist、AspectJ 及反射（使用了 Java 动态代理）等多种设计技术来定制注解。他还展示了如何向类、属性和方法中添加行为，也谈到了如何使用 Aspects 来注解类型和方法。
此外，John 还提到了 Aspect Processing 的好处，如容易实现（需要好工具的支持）、语义细致——可以影响到方法调用，甚至是属性的访问（在这点上，和反射和 APT 不同），还能够集成多个类库的注解，并支持特定的领域抽象。他建议开发人员说，如果 Java 代码可以以接口的方式实现，那就用接口，不要去用注解。他还建议大家不要对所有东西都使用注解，因为 POJO（Plain Old Java Object）要比 HAJO（Heavily Annotated Java Object）好。在演讲中，他列举了其它一些最佳实践准则，比如：
- 注解要添加在最高层次的抽象上（比如在类和方法这两个层次上，注解要尽量添加在类上面）
- 在面对规则的时候，尽量使用合适的默认值，而且只对 exception 添加注解。比外，还要尽量少用参数。
- 将注解作为“规约优于配置”法则的补充（如 Spring）
- 使用反射来增强现有框架（如测试）
- 利用 Javassist 和 CGLIB 框架来产生新的对象，对于底层来说，可以提高字节码转换效率
- 使用 APT 来生成非代码文件
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论