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

“JUnit Cook''s Tour”中的可用性和维护性

简介：在“JUnit: A Cook''s Tour”一文中，作者 Erich Gamma 和 Kent Beck 讨论了 JUnit 的设计。他们指出，与很多成熟框架中的关键抽象一样， TestCase 也有很高的模式密集，易于使用而难以修改。在 AOP@Work 系列的第四 期文章中，Wes Isberg 重温了 Cook''s Tour，说明如何通过使用 AOP 切入点设 计来代替面向对象设计，在一定程度上避免导致成熟的设计难以修改的模式密集 。

即使是最好的 Java™ 程序，也会随着时间的推移而老化。为了满 足新的需求，设计也在不断演化，关键对象承担着各种模式角色，直到它们变得 难以使用或者难以修改，最终不得不重构或者重写系统。面向方面的编程（AOP） 提供了一些将特性结合起来提供服务的更优雅的方法，这些方法可以减少交互、 降低工作量、延长设计和代码的寿命。

本文将分析 Erich Gamma 和 Kent Beck 在“JUnit: A Cook''s Tour”（请参阅 参考资料）一 文中提出的设计。对于他们提出的每种 Java 模式，都给出一种 AspectJ 替代方 案，并说明这种方案是否满足下列标准设计目标：

功能性：提供的服 务是否强大、有用？

可用性：客户能否方便地得到服务？

可扩 展性：程序变化时是否容易扩展或者调整？

结合（分解） 性：能否与其他部分协作？

保护：面对运行时错误或者级联错误， 如何保障 API 的安全？

可理解性：代码是否清晰易懂？

设计的 每一步中，Gamma 和 Beck 都面临着两难选择，比如可用性与可维护性 、可理解性与结合性。在所有的选择中，他们采取的都是简单可用的路线，即便 这意味着要放弃次要的目标。因此，他们的设计使得编写单元测试变得很容易。 但我还是要问一问，如果使用 AOP 的话，能否避免其中一部分设计取舍呢？

这样问也许看起来不够通情达理，有些过于苛求。JUnit 把自己的工 作做得很好，设计中的取舍被很多开发人员所了解，并认为是很正常的做法。要 看看 AOP 能否做得更好，我必须问自己一些问题，比方说，能否增加更多的特性 ，使其更适合那些需要更多服务但不能满足 JUnit 最起码要求的客户。我这样做 不是为了改变 JUnit，而是要在达到主要目标的同时不放弃次要的设计目标。

本文中所有的例子都使用了 AspectJ，但也可用于其他 AOP 方法， 而且即使刚接触 AspectJ，这些例子也很容易理解。（事实上，阅读过 Cook''s Tour 或者了解设计模式，可能要比您使用过 AspectJ 或 JUnit 更 有帮助。）

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

使用 Command 模式还是进行假设？

下面是 Gamma 和 Beck 写在“JUnit: A Cook''s Tour”开头的一段话：

测试用例通常存在于开发人员的脑子里，但实现起来有不同的方式， 如打印语句、调试器表达式、测试脚本。如果想要让测试处理起来更容易，则必 须使它们成为对象。

为了使测试成为对象，他们使用了 Command 模式， 该模式“将请求封装成对象，从而可以……建立请求队列或者 记录请求”。能不能再简单一点呢？

既然焦点是可用性，有点 奇怪的是，Gamma 和 Beck 也了解开发人员可以用不同的方式编写测试，但他们 却坚持认为，开发人员应该只用一种方式编写测试，即封装成一个对象。为什么 这样做呢？为了让测试使用起来更容易。可难就难在：要享受服务的好处，就必 须按照这种形式。

这种权衡影响了设计的成形和演化。可以以特定 客户机为目标，按照某种可用性和能力的组合来构建系统。如果客户机改变了， 那么可以增加一些层次或者改变可用性与能力的组合，每次都

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