如何使用通知来实现特性，同时又避免模式密集带来的危险呢？在类中添加新 特性时，每个新成员都能看到其他可见的成员，这增加了理论上的复杂性。相反 ，AspectJ 最大限度地减少了通知之间的交互。一个连接点上的两个通知彼此是 不可见的，它们都只绑定在它们声明的连接点上下文变量中。如果一个通知影响 到另一个通知，并且需要排序，那么我可以规定它们的相对优先级，而不需要知 道所有的通知并规定完整的顺序。每个通知都使用最少的连接点信息，仅透漏类 型安全、异常检查等必需的自身信息。（AspectJ 在 AOP 技术中差不多是惟一支 持这一级别的封装的。）由于减少了交互，与在类中添加成员相比，向连接点添 加通知所增加的复杂性要小得多。

至于 Cook''s Tour 的其他部分，我使用 testCase() 切入点实现了 Gamma 与 Beck 添加到 TestCase 中的特性。在其中的每一步中，我都努力避免他们必须要 做的那些取舍，评估顺序对连接点是否重要，避免对连接点上下文作出假设，支 持能够想到的各种 API 客户机。

AOP@Work: 设计切入点来避免模式密集(4)

是使用模板方法还是使用 around 通知？

使用 Command 封装测试代码之后，Gamma 和 Beck 认识到使用某种通用数据 装置测试的一般流程：“建立数据装置、对装置运行某些代码并检查结果，然后 清除装置”。为了封装该过程，他们使用了 Template Method 模式：

该模式的目的是，“定义操作中算法的框架，将某些步骤推迟到子类中。 Template Method 允许子类重定义算法中的某些步骤，而不需要改变算法的结构 。”

在 JUnit 中，开发人员使用 setUp() 和 cleanUp() 为 TestCase 管理数据 。JUnit 设施负责在运行每个测试用例之前和之后调用这些方法；TestCase 使用 模板方法 runBare() 来实现这一点：

public void runBare() throws Throwable { 　setUp(); 　try { 　　// run the test method 　　runTest(); 　} finally { 　　tearDown(); 　} }

在 AspectJ 中，如果代码需要在连接点之前和之后运行，可以结合使用 before 通知和 after 通知，或者像下面这样单独使用 around 通知：

/** around each test case, do setup and cleanup */ Object around() : testCase() { 　setup(thisJoinPoint); 　try { 　　// continue running the test case join point 　　return proceed(); 　} finally { 　　 cleanup(thisJoinPoint); 　 } }　　　 protected void setup(JoinPoint jp) {} protected void cleanup (JoinPoint jp) {}

这样的通知提供了三个自由度：

可用于支持 around 通知的任何连接点。

可用于任何类型的测试，因为对运行的代码没有任何假设。

AOP@Work: 设计切入点来避免模式密集(5)

通过将装置的建立/清除代码放在可以被覆盖或者委托实现的方法中，可以适 应不同类型测试对象所需的不同的装置管理方式。有些可能管理自己的数据，如 TestCase；有些可能得益于依赖性倒置（dependency inversion），在外部建立 配置。

但是，这些方法都使用 JoinPoint，在连接点提供了可用于任何上下文的 Object（可能包含 this 对象、 target 对象和任何参数）。使用 JoinPoint 将 使 Object

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!