契约式设计或者Design by Contract (DbC)是一种设计计算机软件的方法。这种方法要求软件设计者为软件组件定义正式的，精确的并且可验证的接口，这样，为传统的抽象数据类型又增加了先验条件、后验条件和不变式。这种方法的名字里用到的“契约”或者说“契约”是一种比喻，因为它和商业契约的情况有点类似。
因为Design by Contract是一个属于Eiffel Software的注册商标，很多开发人员用“Programming by Contract”, “Contract Programming”, 或者”Contract-First development“来指代这种方法。
DbC的核心思想是对软件系统中的元素之间相互合作以及“责任”与“义务”的比喻。这种比喻从商业活动中“客户”与“供应商”达成“契约”而得来。例如：
- 供应商必须提供某种产品（责任），并且他有权期望客户已经付款（权利）。
- 客户必须付款（责任），并且有权得到产品（权利）。
- 契约双方必须履行那些对所有契约都有效的责任，如法律和规定等。
同样的，如果在面向对象程序设计中一个类的函数提供了某种功能，那么它要：
- 期望所有调用它的客户模块都保证一定的进入条件：这就是函数的先验条件—客户的义务和供应商的权利，这样它就不用去处理不满足先验条件的情况。
- 保证退出时给出特定的属性：这就是函数的后验条件—供应商的义务，显然也是客户的权利。
- 在进入时假定，并在退出时保持一些特定的属性：不变式。
契约就是这些权利和义务的正式形式。我们可以用“三个问题”来总结DbC，并且作为设计者要经常问：
- 它期望的是什么？
- 它要保证的是什么？
- 它要保持的是什么？
很多编程语言都有对这种断言的支持。然而DbC认为这些契约对于软件的正确性至关重要，它们应当是设计过程的一部分。实际上，DbC提倡首先写断言。
契约的概念扩展到了方法/过程的级别。对于一个方法的契约通常包含下面这些信息：
- 可接受和不可接受的值或类型，以及它们的含义
- 返回的值或类型，以及它们的含义
- 可能出现的错误以及异常情况的值和类型，以及它们的含义
- 副作用
- 先验条件
- 后验条件
- 不变式
- (不太常见) 性能上的保证，如所用的时间和空间
继承中的子类型可以弱化先验条件（但不可以加强它们），并且可以加强后验条件和不变式（但不能弱化它们）。这些原则很接进Liskov代换原则。
所有类之间的关系就是客户与供应商的关系。一个客户在调用供应商的功能时有义务不去违反供应商所需的状态。相应的，供应商也有义务为客户提供它所需的状态和数据。例如，供应商的delete功能要求客户在data buffer当中有数据存在。相应的，供应商要保证当delete功能完成后，data buffer中的数据已被删除。其它的设计契约还有不变式。不变式保证类的状态在任何功能被执行后都保持在一个可接受的状态。
当使用契约时，供应商不应对契约条件是否被满足进行校验。大体的思想是，利用契约条件校验为保护网，在契约被违反的情况下代码要“死翘翘”（fail hard）。DbC的“死翘翘”概念让对契约行为的调试变简单，因为每个过程的行为意图被定义得很清楚。它和一种叫作defensive programming的方法明现不同，在那种方法里，供应商要负责解决先验条件不满足的情况。相对通常的情况下，在DbC和defensive programming中，如果客户违反了先验条件供应商都会抛出异常—由客户来负责解决这种情况。DbC让供应商的工作更简单。
DbC同时也定义了软件模块的正确性条件：
- 如果对一个供应商的调用之前类的不变式和先验条件是真，那么在调用后不变式和后验条件也为真。
- 当调用供应商时，软件模块应保证不违反供应商的先验条件。
因为契约条件在程序运行中不应被违反，它们可以只作为调试代码，或者在发布版本中被移除从而得到更好的性能。
DbC也能帮助代码重用，因为每段代码的契约都被很好的文档化了。模块的契约可以被当做软件文档来 描述模块的行为。
DBC分三种：
1.Post-conditions 后置条件postcondition 表示调用一个方法一定会得到的结果。类似断言Assertion，如果语言不支持断言，那么我们就必须自己写断言，也就是测试驱动了。
2.Pre-conditions 前置条件precondition ，预先保证后置条件必须满足前置条件。
前置条件必须满足，后置条件必须实现，通过契约的前置和后置条件的结合，就不会出现有隐藏的功能obligations，这样，事情清清楚楚地被摆出来。这样设计才能落实为代码，保证正常的对象调用。
3.类不变量class invariant 表示对象状态的断言，执行完任何操作后都都应该被满足，不变量还是对聚合体进行完整性严格定义。
不变性意义非常重要，不变性意思是对象的所有属性必须由其方法来保证一致性。DDD推广到根对象要通过方法保证其聚合体内所有对象的属性保持一致性。比如ForumThread的addMessage就保证加入新的Message以后，其聚合体内相关属性一致修改，保持不变性是一个排他性过程，或者说需要由锁或事务来完成，这又和伸缩性scalable设计有关。
http://www.jdon.com/jivejdon/forum/messageList.shtml?thread=36063&message=23122565#23122565
via：http://www.jdon.com/36303