用AOP增强契约：用AspectJ为Java软件开发加入契约式设计

用AOP增强契约：用AspectJ为Java软件开发加入契约式设计2011-09-07 ibm Filippo Diotalevi简介：在开发企业软件时，Java 代码经常需要与外部组件交互。不管应用程序必须与遗留应用程序、外部系统还是第三方库通信，使用不能控制的组件会引入非预期结果的风险。IBM 的 IT 专家 Filippo Diotalevi 展示了，面向方面的编程（AOP）如何通过帮助您在保持代码的干净和灵活性的同时，设计和定义组件之间的明确契约，从而降低这种风险。

契约式设计（Design by Contract）（DBC）是面向对象的软件设计中的一种技术，它的目的是保证软件质量、可靠性和可重用性。DBC 中的关键考虑是可以通过以下做法实现这个目标：

尽可能准确地规定组件之间的通信。

定义通信过程中的相互责任和预期的结果。

这些相互责任称为契约，用断言检查应用程序是否满足契约。简单地说，断言是插入到程序执行中的特定点的布尔表达式，它必须为真。失败的断言通常是软件 bug 的症兆，所以必须将它报告给使用者。

在处理外部组件或者库，并需要保证应用程序传递给它们的数据和从它们那里接收的数据是正确的时候，DBC 特别有用。本文将展示一个抽象的基础设施和一个示例应用程序，前者使用面向方面的编程（AOP）实现 DBC，后者与外部组件建立契约。

断言和 Java 语言

DBC 识别三种基本的断言类型：

前置条件：客户为了正确调用外部组件而必须满足的责任。

后置条件：执行外部组件后的预期结果。

不变量：在执行了外部组件后维持不变的条件。

Java 语言原来没有提供对断言的天然支持。 assert 语句是在版本 1.4 中加入的。不过，在日常编码中使用 DBC 会是一种挑战。事实上，大多数常用的方法 ── 在应用程序代码中直接加入前置和后置断言 ── 在代码模块化和可重用性方面有严重的缺点。这种方法是纠缠的代码的一个活生生的例子：它混合了业务逻辑代码与断言所需的非功能代码。这种代码是不灵活的，因为不能在不改变应用程序代码的情况下改变或者删除断言。

对这个问题的理想解决方案要满足四个要求：

透明性：前置和后置条件代码不与业务逻辑混合。

可重用性：解决方案的大多数部件是可重用的。

灵活性：可以用简单的方式增加、删除和修改断言模块。

简单性：可以用简单的语法指定断言。