体验Java 1.5中面向(AOP)编程
添加时间: 2006-2-18 11:53:11 作者: JAVA教程 阅读次数:43 来源: http://www.d9soft.com
为了填补这个空缺，我们已经发明了一些简单的替代品，例如日志文件（典型情况下用于服务器处理）和状态条（用于GUI应用程序）。但是，由于这些工具只能捕捉和报告可用信息的一个很小的子集，并且通常必须把这些信息用容易理解的方式表现出来，所以程序员趋向于把它们明确地编写到应用程序中。而这些代码会缠绕着应用程序的业务逻辑，当开发者试图调试或了解核心功能的时候，他们必须"围绕这些代码工作"，而且还要记得功能发生改变后更新这些代码。我们希望实现的真正功能是把状态报告集中在某个位置，把单个状态消息作为元数据（metadata）来管理。
在本文中我将考虑使用嵌入GUI应用程序中的状态条组件的情形。我将介绍多种实现这种状态报告的不同方法，从传统的硬编码习惯开始。随后我会介绍Java 1.5的大量新特性，包括注解（annotation）和运行时字节码重构（instrumentation）。
状态管理器（StatusManager）
我的主要目标是建立一个可以嵌入GUI应用程序的JStatusBar Swing组件。图1显示了一个简单的Jframe中状态条的样式。
由于我不希望直接在业务逻辑中引用任何GUI组件，我将建立一个StatusManager（状态管理器）来充当状态更新的入口点。实际的通知会被委托给StatusState对象，因此以后可以扩展它以支持多个并发的线程。图2显示了这种安排。
现在我必须编写代码调用StatusManager的方法来报告应用程序的进程。典型情况下，这些方法调用都分散地贯穿于try-finally代码块中，通常每个方法一个调用。
public void connectToDB (String url) {
StatusManager.push("Connecting to database");
try {
...
} finally {
StatusManager.pop();
}
}
这些代码实现了我们所需要功能，但是在代码库中数十次、甚至于数百次地复制这些代码之后，它看起来就有些混乱了。此外，如果我们希望用一些其它的方式访问这些消息该怎么办呢？在本文的后面部分中，我将定义一个用户友好的异常处理程序，它共享了相同的消息。问题是我把状态消息隐藏在方法的实现之中了，而没有把消息放在消息所属的接口中。
面向属性编程
我真正想实现的操作是把对StatusManager的引用都放到代码外面的某个地方，并简单地用我们的消息标记这个方法。接着我可以使用代码生成（code-generation）或运行时反省（introspection）来执行真正的工作。XDoclet项目把这种方法归纳为面向属性编程（Attribute-Oriented Programming），它还提供了一个框架组件，可以把自定义的类似Javadoc的标记转换到源代码之中。
但是，JSR-175包含了这样的内容，Java 1.5为了包含真实代码中的这些属性提供了一种结构化程度更高的格式。这些属性被称为"注解（annotations）"，我们可以使用它们为类、方法、字段或变量定义提供元数据。它们必须被显式声明，并提供一组可以包含任意常量值（包括原语、字符串、枚举和类）的名称-值对（name-value pair）。
注解（Annotations）
为了处理状态消息，我希望定义一个包含字符串值的新注解。注解的定义非常类似接口的定义，但是它用@interface关键字代替了interface，并且只支持方法（尽管它们的功能更像字段）：
public @interface Status {
String value();
}
与接口类似，我把@interface放入一个叫做Status.java的文件中，并把它导入到任何需要引用它的文件中。
对我们的字段来说，value可能是个奇怪的名称。类似message的名称可能更适合；但是，value对于Java来说具有特殊的意义。它允许我们使用@Status("...")代替@Status(value="...")来定义注解，这明显更加简捷。
我现在可以使用下面的代码定义自己的方法：
@Status("Connecting to database")
public void connectToDB (String url) {
...
}
请注意，我们在编译这段代码的时候必须使用-source 1.5选项。如果你使用Ant而不是直接使用javac命令行建立应用程序，那么你需要使用Ant 1.6.1以上版本。
作为类、方法、字段和变量的补充，注解也可以用于为其它的注解提供元数据。特别地，Java引入了少量注解，你可以使用这些注解来定制你自己的注解的工作方式。我们用下面的代码重新定义自己的注解：
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.SOURCE)
public @interface Status {
String value();
}
@Target注解定义了@Status注解可以引用什么内容。理想情况下，我希望标记大块的代码，但是它的选项只有方法、字段、类、本地变量、参数和其它注解。我只对代码感兴趣，因此我选择了METHOD（方法）。
@Retention注解允许我们指定Java什么时候可以自主地抛弃消息。它可能是SOURCE（在编译时抛弃）、CLASS（在类载入时抛弃）或RUNTIME（不抛弃）。我们先选择SOURCE，但是在本文后部我们会更新它。
为了实现这些功能，我必须对已有的代码进行稍微的修改。首先，为了确保在运行时@Status注解是可以看到的，我就必须再次更新@Retention，把它设置为@Retention(RetentionPolicy.RUNTIME)。请记住，@Retention控制着JVM什么时候抛弃注解信息。这样的设置意味着注解不仅可以被编译器插入字节码中，还能够使用新的Method.getAnnotation(Class)方法通过反射来进行访问。
现在我需要安排接收代码中没有明确处理的任何异常的通知了。在Java 1.4中，处理任何特定线程上未处理异常的最好方法是使用ThreadGroup子类并给该类型的ThreadGroup添加自己的新线程。但是Java 1.5提供了额外的功能。我可以定义UncaughtExceptionHandler接口的一个实例，并为任何特定的线程（或所有线程）注册它。
请注意，在例子中为特定异常注册可能更好，但是在Java 1.5.0beta1（#4986764）中有一个bug，它使这样操作无法进行。但是为所有线程设置一个处理程序是可以工作的，因此我就这样操作了。
现在我们拥有了一种截取未处理异常的方法了，并且这些异常必须被报告给用户。在GUI应用程序中，典型情况下这样的操作是通过弹出一个包含整个堆栈跟踪信息或简单消息的模式对话框来实现的。在例子中，我希望在产生异常的时候显示一个消息，但是我希望提供堆栈的@Status描述而不是类和方法的名称。为了实现这个目的，我简单地在Thread的StackTraceElement数组中查询，找到与每个框架相关的java.lang.reflect.Method对象，并查询它的堆栈注解列表。不幸的是，它只提供了方法的名称，没有提供方法的特征量（signature），因此这种技术不支持名称相同的（但@Status注解不同的）重载方法。
实现这种方法的示例代码可以在peekinginside-pt2.tar.gz文件的/code/04_exceptions目录中找到。
你可以发现，动态的（Dynamic）方法是各种方案的良好组合。与使用重构的所有示例类似，它提供了方法开始或终止时刻的明确的回调，因此你的应用程序可以准确地跟踪运行时并立即为用户提供反馈信息。但是，它还能够取消某种方法的重构（它被过于频繁地调用），因此它不会受到其它的重构方案遇到的性能问题的影响。它没有包含编译时步骤，并且它没有增加类载入过程中的额外的工作。
未来的趋势
我们可以给这个项目增加大量的附件特性，使它更加适用。其中最有用的特性可能是动态的状态信息。我们可以使用新的java.util.Formatter类把类似printf的模式替换（pattern substitution）用于@Status消息中。例如，我们的connectToDB(String url)方法中的@Status("Connecting to %s")注解可以把URL作为消息的一部分报告给用户。
在源代码重构的帮助下，这可能显得微不足道，因为我将使用的Formatter.format方法使用了可变参数（Java 1.5中增加的"魔术"功能）。重构过的版本类似下面的情形：
public void connectToDB (String url) {
Formatter f = new Formatter();
String message = f.format("Connecting to %s", url);
StatusManager.push(message);
try {
...
} finally {
StatusManager.pop();
}
}
不幸的是，这种"魔术"功能是完全在编译器中实现的。在字节码中，Formatter.format把Object[]作为参数，编译器明确地添加代码来包装每个原始的类型并装配该数组。如果BCEL没有加紧弥补，而我又需要使用字节码重构，我将不得不重新实现这种逻辑。
由于它只能用于重构（这种情况下方法参数是可用的）而不能用于取样，你可能希望在启动的时候重构这些方法，或最少使动态实现偏向于任何方法的重构，还可以在消息中使用替代模式。
你还可以跟踪每个重构的方法调用的启动次数，因此你还可以更加精确地报告每个方法的运行次数。你甚至于可以保存这些次数的历史统计数据，并使用它们形成一个真正的进度条（代替我使用的不确定的版本）。这种能力将赋予你在运行时重构某种方法的一个很好的理由，因为跟踪任何独立的方法的开销都是很能很明显的。
你可以给进度条增加"调试"模式，它不管方法调用是否包含@Status注解，报告取样过程中出现的所有方法调用。这对于任何希望调试死锁或性能问题的开发者来说都是无价之宝。实际上，Java 1.5还为死锁（deadlock）检测提供了一个可编程的API，在应用程序锁住的时候，我们可以使用该API把进程条变成红色。
本文中建立的基于注解的重构框架组件可能很有市场。一个允许字节码在编译时（通过Ant事务）、启
动时（使用ClassTransformer）和执行过程中（使用Instrumentation）进行重构的工具对于少量其它新项目来说毫无疑问地非常有价值。
总结
在这几个例子中你可以看到，元数据编程（meta-programming）可能是一种非常强大的技术。报告长时间运行的操作的进程仅仅是这种技术的应用之一，而我们的JStatusBar仅仅是沟通这些信息的一种媒介。我们可以看到，Java 1.5中提供的很多新特性为元数据编程提供了增强的支持。特别地，把注解和运行时重构组合在一起为面向属性的编程提供了真正动态的形式。我们可以进一步使用这些技术，使它的功能超越已有的框架组件（例如XDoclet提供的框架组件的功能）。
上一篇文章: 如何成为一名Java初级程序员 下一篇文章: Java中实现基于Aspectwerkz的AOP
相关文章: