1. Design by Contract的六大原则:
原则1 区分命令和查询。查询返回一个结果，但不改变对象的可见性质。命令改变对象的状态，但不返回结果。
原则2 将基本查询同派生查询区分开。派生查询可以用基本查询来定义。
原则3 针对每个派生查询，设定一个后验条件，使用一个或多个基本查询的结果来定义它。这样一来，只要我们知道基本查询的值，也就能知道派生查询的值。
原则4 对于每个命令都撰写一个后验条件，以规定每个基本查询的值。结合“用基本查询定义派生查询”的原则(原则3)，我们现在已经能够知道每个命令的全部可视效果。
原则5 对于没个查询和命令，采用一个合适的先验条件。先验条件限定了客户调用查询和命令的时机。
原则6 撰写不变式来定义对象的恒定特性。类是某种抽象的体现，应当将注意力集中在最重要的属性上，以建立关于类抽象的正确概念模型。
2. Design by Contract的六大准则:
准则1 在适当的地方添加物理限制。尤其是那些需要限制变量不应该为void的地方。
准则2 先验条件中尽可能使用高效的查询。如果有必要，可以增加高效的派生查询，并在其后验条件中确保其与较低效的基本查询之间的等价关系。
准则3 用不变式限定属性。如果一个派生查询被实现为一个属性，则应通过类中不变式的断言保证它与其他查询保持一致。在一个类的开发过程中，通常应该先把断言检测的级别设为***，使先验条件、后验条件和不变式都得到检测；一旦通过了检测和测试，一般就可以降低断言检测的级别，只检测先验条件，以提过代码的运行效率。
准则4 为了支持特性的重定义，用相应的先验条件确保每个后验条件。这样就允许在子类开发过程中进行各种不可预见的重定义。
准则5 将预期发生的变化和框定规则这两种不同的限制分别放置在不同的类中。这使开发者在扩展已有类时享有更多的***。
准则6 若有保密性要求，则违背保密性的查询只能被设为私有熟悉在契约中使用。这里的“设为私有”，是对“在契约中使用了该查询的类”之下的层次而言，至于类之上的层次，这个查询当然是可以使用的。
本文转自Silent Void博客园博客，原文链接：http://www.cnblogs.com/happyhippy/archive/2006/12/18/601303.html，如需转载请自行联系原作者
