Java 理论与实践: 平衡测试，第 3 部分：用方面检验设计约束

核心提示： swingMethods() 切入点包含对 javax.swing 包中的所有方法（包括构造函数）的调用，extendsSwing() 切入点代表对所有扩展自 JComponent 或任何 Swing 模型类的类中方法的全部调用，Java 理论与实践: 平衡测试，第 3 部分：用方面检验设计约束

swingMethods() 切入点包含对 javax.swing 包中的所有方法（包括构造函数）的调用。extendsSwing() 切入点代表对所有扩展自 JComponent 或任何 Swing 模型类的类中方法的全部调用。safeMethods() 切入点代表一些已知可以从任何线程安全调用的 Swing 方法。

SwingThreadAspect 并不完美，但是足够了。safeMethods() 切入点没有完全枚举线程安全方法，而且 extendsSwing() 切入点可能也没有包含所有经常被扩展的 Swing 类。但是我们不会把它们用于生产 —— 只是用它们进行测试。它能够不必为每个程序创建新的测试用例就发现 bug，而这就是它的价值所在。而且，像大多数 bug 探测器一样，它可能会在以前以为是正确的程序中找到 bug。

在调试对象中切换

方面的另一个好应用就是在类的正式版本和 “调试” 版本之间进行切换。创建一个类的调试版本是相当普遍的情况，例如创建一个带有更多日志或错误检测的版本，这个版本因为副作用或性能问题而不适合在生产中使用。但是在需要的时候在调试版本中切换，会很烦琐或者容易出错。如果对象是通过构造函数实例化的，就不得不在代码中找到所有调用构造函数的地方。缓解修改所有构造函数调用的不方便性的一种常用技术是，改用工厂来实例化对象，但是只为了在生产版本和调试版本之间进行选择而使用工厂，会增加复杂性或带来安全漏洞。

如果目的是为了 “在所有实例化 Foo 的地方，都换成实例化 DebuggingFoo”，那么方面为做这件事提供了非常可靠且不需要修改程序的简单机制。作为示例，清单 4 显示了一个方面，它有助于发现死锁，把 ReentrantLock 的所有实例化都替换成 DebuggingLock。（请注意，AspectJ 只修改要求 AspectJ 编译器处理的代码中的调用；Java™ 类库本身中对 ReentrantLock 的实例化不会被替换，除非特意把方面编织到平台库中。）