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

使用组合还是使用递归？

Cook''s Tour 认识到装置必须运行大量的测试——“一套一套的测试”。

Composite 模式可以很好地满足这种要求：

该模式的目的是，“把对象组合到树状结构中，以表示部分-整体关系。组合 使客户机能够统一地看待单个对象和对象的组合。”

Composite 模式引入了三个参与方：Component、Composite 与 Leaf。 Component 声明了我们希望用来与测试交互的接口。Composite 实现了该接口， 并维护一个测试集合。Leaf 表示 Composite 中的测试用例，该用例符合 Component 接口。

这就形成了 JUnit 设计环，因为 Test.runTest(..) Command 接口是 Leaf TestCase Composite TestSuite 实现的 Component 接口 。

可维护性

Cook''s Tour 支出，“应用 Composite 时，我们首先想到的是应用它是多么 复杂。”该模式中，节点和叶子的角色被添加到已有的组件上，并且它们都需要 知道自己在实现组件接口时的职责。它们之间定义了调用协议，并由节点实现， 节点也包含子节点。这意味着节点知道子节点，同时装置也知道节点。

在 JUnit 中，TestSuite（已经）非常了解 TestCase，JUnit 测试运行者假 设要通过加载 suite 类来生成一个套件。从配置中可以看到，支持可配置的测试 需要管理测试套件的生成。组合增加了模式密集。

Composite 模式在 AspectJ 中可使用内部类型声明实现，如上面关于配置的 一节所述。在 AspectJ 中，所有成员都是在一个方面中声明的，而不是分散在已 有的类中。这样更容易发现角色是否被已有类的关注点污染了，在查看实现的时 候也更容易了解这是一个模式（而不仅仅是类的另一个成员）。最后，组合是可 用抽象方面实现的模式之一，可以使用标签接口来规定担任该角色的类。这意味 着可以编写可重用的模式实现。（关于设计模式的 AspectJ 实现的更多信息，请 参阅 Nicholas Lesiecki 所撰写的“Enhance design patterns with AspectJ” ，参见 参考资料。）

递归

AspectJ 能否不借助 Composite 模式而满足原来的需要呢？AspectJ 提供了 运行多个测试的很多方法。上面关于配置的例子是一种方法：把一组子测试和一 个测试关联，使用通知在切入点 recursing() 选择的连接点上递归运行各个成分 。该切入点规定了应该递归的组合操作：

// in abstract aspect AComposite /** tag interface for subaspects to declare */ public interface IComposite {} /** pointcut for subaspects to declare */ protected abstract pointcut recursing(IComposite c); /** composites have children */ public ArrayList<IComposite> IComposite.children = new ArrayList<IComposite>(); /** when recursing, go through all subtree targets */ void around(IComposite c) : recursing(c) { // recurse... }

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

下面说明了如何将该

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