追求代码质量: 用 AOP 进行防御性编程

核心提示： 很自然，我也会编写一个快速测试用例来验证我的检验是否真能避免 NullPointerException，追求代码质量: 用 AOP 进行防御性编程(4)，如清单 4 所示： 清单 4. 验证 null 检验@Test(expectedExceptions={RuntimeException.cl

很自然，我也会编写一个快速测试用例来验证我的检验是否真能避免 NullPointerException，如清单 4 所示：

清单 4. 验证 null 检验

@Test(expectedExceptions={RuntimeException.class})　
public　void　verifyHierarchyNull()　throws　Exception{　
　Class　clzz　=　null;　
　HierarchyBuilder.buildHierarchy(null);　　
}　　　

在本例中，防御性编程似乎解决了问题。但仅依靠这项策略会存在一些缺陷。

防御的缺陷

关于断言

清单 3 使用一个条件来验证 clzz 的值，实际上 assert 也同样好用。使用断言，无需指定条件，也不需要指定异常语句。在启用了断言的情况下，防御性编程的关注点全部由 JVM 处理。

尽管防御性编程有效地保证了方法的输入条件，但如果在一系列方法中使用它，不免过于重复。熟悉面向方面编程（或 AOP）的人们会把它认为是横切关注点，这意味着防御性编程技术横跨了代码库。许多不同的对象都采用这些语法，尽管从纯面向对象的观点来看这些语法跟对象毫不相关。

而且，横切关注点开始渗入到契约式设计（DBC）的概念中。DBC 是这样一项技术，它通过在组件的接口显式地陈述每个组件应有的功能和客户机的期望值来确保系统中所有的组件完成它们应尽的职责。从 DBC 的角度讲，组件应有的功能被认为是后置条件，本质上就是组件的责任，而客户机的期望值则普遍被认为是前置条件。另外，在纯 DBC 术语中，遵循 DBC 规则的类针对其将维护的内部一致性与外部世界有一个契约，即人所共知的类不变式。

契约式设计

我在以前的一篇关于用 Nice 编程的文章中介绍过 DBC 的概念，Nice 是一门与 JRE 兼容的面向对象编程语言，它的特点是侧重于模块性、可表达性和安全性。有趣的是，Nice 并入了功能性开发技术，其中包括了一些在面向方面编程中的技术。功能性开发使得为方法指定前置条件和后置条件成为可能。