契约式编程

契约式编程是编程的一种方法。那么什么是契约式编程呢？我想这个概念是从“合同”演变过来的。

在人类的社会活动中，契约一般是用于两方，一方（供应者）为另一方（客户）完成一些任务。每一方都期待从契约中获得利益，同时也要接受一些义务。通常，一方视为义务的对另一方来说是权利。契约文档要清楚地写明双方的权利与义务。

契约合同能保障双方的利益，对客户来说，合同规定了供应者要做的工作；对供应者来说，合同说明了如果约定的条件不满足，供应者没有义务一定要完成规定的任务。

同样的道理也适合于软件。设想一个软件单元E。它要达到它的目的（履行契约）， E使用的策略可能会包括一系列的子任务，t1, ... tn。如果子任务ti 不是那么简单的，它得调用另一个功能例程（routine)R。换句话说，E把子任务转包给R。这样的情形应该被一个很好定义的“登记表” (roster）来管理双方的义务与权利－－契约。

假如ti是一项任务，要求把一个给定的元素插入到一个有限容量的字典中。此处字典是一个（名－值）表，每一个元素（值）通过一个作为关键字的字符串（名）存取。（译者注：这里“元素”可以理解成一个任意的数据项）。

简而言之，就是函数调用者应该保证传入函数的参数是符合函数的要求，如果不符合函数要求，函数将拒绝继续执行。如果按照契约式编程的思想编写代码，就要求我们写函数时检查函数参数。有时候是简单的判断某个参数不能为空，或者数值不能小于0。如果在项目中全面应用契约式编程，则应该有一个“契约框架”帮我们来做这些事情。

契约与我们通常所说的商业契约很相似，有以下几个特点：

契约关系的双方是平等的，对整个bussiness的顺利进行负有共同责任，没有哪一方可以只享有权利而不承担义务。
契约关系经常是相互的，权利和义务之间往往是互相捆绑在一起的；
执行契约的义务在我，而核查契约的权力在人；
我的义务保障的是你的利益，而你的义务保障的是我的利益；
将契约关系引入到软件开发领域，尤其是面向对象领域之后，在观念上给我们带来了几大冲击：

一般的观点，在软件体系中，程序库和组件库被类比为server，而使用程序库、组件库的程序被视为client。根据这种C/S关系，我们往往对库程序和组件的质量提出很严苛的要求，强迫它们承担本不应该由它们来承担的责任，而过分纵容client一方，甚至要求库程序去处理明显由于 client错误造成的困境。客观上导致程序库和组件库的设计和编写异常困难，而且质量隐患反而更多；同时client一方代码大多松散随意，质量低劣。这种情形，就好像在一个权责不清的企业里，必然会养一批尸位素餐的混混，苦一批任劳任怨，不计得失的老黄牛。引入契约观念之后，这种C/S关系被打破，大家都是平等的，你需要我正确提供服务，那么你必须满足我提出的条件，否则我没有义务“排除万难”地保证完成任务。