所以，严格来说，契约式设计看起来可能根本不是 AOP 技术的备选方案。但 是，虽然合约本身是 BankAccount 域所必不可少的部分，但这个信息的使用则 是 横切的。Contract4J 的兴趣在于强制用编程的方式实现合约，而 Contract4J 标注的设计目的就是为了支持这个目标。不过，在自动生成单元测 试的工具或 IDE 中，可以方便地利用通过标注公开的合约信息：如果组件使用 不当，就会警告用户。

使用标注，Contract4J 定义了模式形式的协议，即一种接口，用来表达合约 信息。在这一方面，Contract4J 类似于 Observer 模式：标注形式的合约规范 是 “可以观察的”，可以由工具操作。协议用结构化英语的形式表达，例如方 法后置条件可以这么表达：

if @Contract is on a class and @Post is on a method, then get the @Post expression string and evaluate it, aborting if false.

Contract4J 方面用 AspectJ 实现这一逻辑。方面不要求被测试类的显式信 息，例如它们的名称或方法名称。方面关心的只是标注。所以，方面可以完全保 持通用和可重用。可以把这与许多典型的 AspectJ 方面对比，后者编写时显式 地引用了特定的包和类，从而使重用和演变更加困难。

一个类似的使用标注来承载元信息的示例是，定义来与 Hibernate 和 EJB3 一起用于表达 POJO 中持久性需求的标注集（请参阅 参考资料）。

AOP@Work: 用Contract4J进行组件设计-用契约式设计和AspectJ改进软件(6)

方面接口的挑战

当然，基于标注的元信息能走多远，依赖于方面设计技术能走多远。就像使 用对象设计时，我们应当预料到创建可重用的、松散耦合的、面向方面的系统和 可重用的、通用的方面库会大量地要求基于接口的技术。接口定义了耦合组件的 适当抽象，却没有公开太多细节。所以，在软件发展的过程中，接口要比底层组 件更稳定。

而就方面来说，它们带来了独特的挑战。从方面的性质来说，方面实际上广 泛地接触到了系统的其余部分，而对象组件则更加 “本地化”。方面还有用新 的、更精细的方式修改对象状态和行为的能力，从而引起了对维护系统完整性、 健壮性、甚至整体理解的担心。

为了解决这些问题，研究人员和实践人员都在探寻方面/对象系统的接口不应 只包含我们已经习惯的方法和状态信息，还应当包含合约信息，合约信息限定方 面允许对其他组件所做的修改（听起来有点熟悉？）例如，方面可能不允许对组 件做状态修改，或者出于性能和安全原因而被限制为不能建议某些 “关键区域 ”。

所以，不是方面切入点直接耦合到组件细节，比如特定的命名规范，方面而 是要耦合到组件实现的接口。组件将用接口向方面公开允许的连接点和状态信息 。方面将只通过公开的接口建议组件。由于接口要比实现它们的组件更稳定，所 以耦合也会变得更稳定，在系统发展的时候，也更能跟得上变化。就像在对象系 统中一样，基于方面的编程可以让设计人员能够更容易地构建健壮的、大型的、 仍然可以重用的方面/对象系统。

结束语

Contract4J 使用 Java 5 标注，以直观的方式使得契约式设计测试的定义变 得更有效更简单。这些测试在测试时自动计算，有助于捕获代码中的逻辑错误。 Contract4J 利用了 AspectJ 的威力，却不要求开发人员是使用 AspectJ 的专 家。

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