Composition # recursion Configuration # defining test, identity Context # reporting results Fixture # managing test data test # underlying test

作为设计抽象的切入点

上面就是我对 JUnit Cook''s Tour 的评述。我所讨论的所有面向方面的设计 解决方案都可在本文的代码压缩包中找到。这些解决方案具有以下特点：

依赖于切入点而不是类型，要么不作任何假定，要么将上下文规格推迟到具体 的子方面中。

都是独立的，可单独使用。

可以在同一系统中多次重用。

可以共同工作，有时候需要定义它们的相对优先级。

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

不需要修改客户机部分。

与 JUnit 相比，可做的工作更多，需要客户机的干预也更少。

对于给定的 Java 模式，AspectJ 提供了完成同一任务的多种方式，有时候是一个简单的短语 。这里采用了在可重用解决方案中使用切入点和做最少假定的方法，这些主要是 为了说明 AspectJ 如何通过封装通知和切入点来减少交互，从而很容易在连接点 上改变行为。有时候，可以使用具体的（非重用的）方面，将特性组合到一个方 面中；或者使用内部类型声明来实现对应的 Java 模式可能更清楚。但是这些解 决方案示范了最大限度地减少一个连接点上的交互的技术，从而使将切入点用作 一流设计抽象变得更简单。

切入点仅仅是减少重重假设的设计方法的第一步。应在可能不需要对象的地方 真正利用切入点。如果对象是必需的，那么应该尝试在方面中使用内部类型声明 来组合对象，从而使不同的（模式）角色保持区别，即使在同一个类中定义也是 如此。与面向对象编程一样，应避免不同的组件了解对方。如果必须彼此了解， 比较具体的一方应该知道抽象的一方，装配器应该知道各个部分。如果彼此都要 知道，那么这种关系应该尽量简练、明确、稳定和可实施的。

全速 AOP

AspectJ 1.0 是三年前发布的。多数开发人员都看过并尝试了 AspectJ 的入 门应用，即模块化跟踪这样的横切关注点。但是有些开发人员更进一步，尝试进 行我所说的“全速 AOP”：

设计失败和设计成功一样平常。

重用（或者可重用）切入点这样的横切规 格。

方面可能有很多互相依赖的成分。

方面用于倒置依赖和解耦代码。

方面用于连接组件或子系统。

方面打包成可重用的二进制库。

系统中有很 多方面。一些对另一些无关紧要，但还有一些则依赖于另一些。

虽然方面可能 是不可插接的，但是插入后可以增加基本功能或者结构。

可以重构库代码创建 更好的连接点模型。

是什么让一些开发人员裹足不前呢？在最初听说 AOP 或 者学习基础知识后，似乎进入了一个平台阶段。比如进入了这样的思维陷阱：

AOP 模块化了横切关注点，因此我要在代码中寻找横切关注点。我找到了所有 需要的跟踪、同步等关注点，因此不再需要做其他事了。

这个陷阱就像在面向 对象编程初期单纯按照“is-a”和“has-a”思考一样。寻找单个的关注点（即使 是横切关注点），就丢失了关系和协议，在规范化为模式时，关系和协议是编码 实践的支柱。

另一种思维陷阱是：

AOP 模块化横切关注点。因此应该寻找那些分散和纠缠在代码中的代码。这些 代码似乎都很好的本地化了，因此不需要 AOP。

虽然分散和纠缠可能是非模块 化横切关注点的标志，AOP 除了收集分散的代码或者纠缠在一起的复杂方法或对 象之外，还有很多用处。

最后，最难以避开的思维陷阱是：

AOP 用新的语言设施补充了面向对象编程，因此应该用于解决面向对象编程不 能解决的关注点。面向对象编程解决了所有关注点，因此我不需要 AOP。

本文 中没有讨论横切关注点，我重新实现的多数解决方案照目前来看都是经过很好模

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