对于开发 0 bug 代码的思考——Design by Contract 契约设计

前言

最近在开发一个验证框架，希望能够降低代码的bug率，提升质量；不知不觉就来到了Design By Contract，感觉这是个方向。

本文主要是批判一下现有的契约设计问题，提出自己的看法，很希望得到一些牛人的指教。

研究现状简单分析

Design by Contract（DbC）是个天才（我觉得）叫Bertrand Meyer提出来的。那个家伙同时还搞出了个Eiffel的东西，是对DbC的实践（Practise）。我先简单介绍下DbC, 下文是一个范型字典DICTIONARY [ELEMENT]:的put方法定义:

put (x: ELEMENT; key: STRING) is
-- Insert x so that it will be retrievable through key.
require
count <= capacity
not key.empty
do
... Some insertion algorithm ...
ensure
has (x)
item (key) = x
count = old count + 1
end
大概意思是，调用这个方法，要求(require)是xxxx；这个方法干了什么（do），这个方法结束后，保证了什么输出（ensure）。

具体可以看：http://www.eiffel.com/developers/knowledgebase/design_by_contract.html

换句话说，一个方法有了前置条件(pre condition)、后置条件(post condition)，调用起来就有了保证。

然后，一些人就开始做文章了。在c#领域里面，ms也没有闲着。首先是Spec#，个人感觉是一种模仿Eiffel的语言，一个例子：

Spec#

代码

class A
{
public void Foo(
[Supervise(CheckVar1)] // 对传入参数进行验证
string var1,
[Supervise(CheckVar2)] // 对传入参数进行验证
string var2)
{
int interval = 1;
B b = new B();
b.Foo(interval);
}
}
然后验证过程在新的方法实现了。这样开发，就变得非常的清晰了。

小结与后续

在design by contract的框架开发下，大部分的类的方法会使用自然语言去描述contract；到了关键的边缘区域（内部与外部交互的区域），会查询此区域的contract（当然是自然语言描述的集合），然后我们再针对这些contract去检视传入参数。
如果有些内部类会履行某个类的contract，那么这个类的履行也需要使用检视。

如果我的想法能够在现有的技术下实现了，我觉得出现一个全新的开发过程，一种新的practise。以后的程序员会在class标注各种contract，然后最终会在某些类上使用Supervise，同时在某些类可以查看他需要履行的contract是什么。

这样开发起来，bug会降低到0，不是梦想。

(偶狂敲了1个小时，吐了几千字的废话，希望各位支持一下，能给点思路，指出我的错误。在此感谢了！)

技术支持

reborn_zhang@hotmail.com

zc22.cnblogs.com